容器内存限制（-m）不等于数据库可用内存，MySQL需设innodb_buffer_pool_size≤容器内存60%（如4G容器配2G），PostgreSQL需显式配置shared_buffers（如1GB）和effective_cache_size（如2GB），且必须调高WSL2总内存并执行wsl --shutdown生效。
容器内存限制（-m）不等于实际可用内存
给 mysql 或 postgres 容器加 -m 4g，不代表数据库进程能用满 4GB。JVM（如 Neo4j）、PostgreSQL 的 shared_buffers、MySQL 的 innodb_buffer_pool_size 都需要显式配置，否则它们会按宿主机总内存（非容器内存）自动计算，极易超限被 OOM Killer 杀掉。
典型表现是容器反复退出，docker ps -a 显示 Exited (137)，而 docker stats 看 RSS 还不到 2GB。
- MySQL 容器必须设
innodb_buffer_pool_size=2G（不超过容器内存的 60%） - PostgreSQL 容器建议设
shared_buffers=1GB+effective_cache_size=2GB - Neo4j 必须双绑定：
-e NEO4J_dbms_memory_heap_max__size=2G且--memory=4g - 所有数据库镜像都应禁用 swap：
--memory-swap=-1，避免因 swap 延迟触发误杀
WSL2 虚拟机内存才是总闸门
Docker Desktop 在 Windows 上默认走 WSL2 后端，它本质是一台 Linux 虚拟机，所有容器共享其内存池。GUI 里调 Resources → Memory 滑块（默认 2GB），改的是这台虚拟机的上限，不是单个容器的。
如果你跑 MySQL + Redis + Spring Boot 三个容器，每个设 -m 2g，但 WSL2 总内存只有 2GB，照样集体 OOM——因为它们争抢的是同一块物理内存。
- 查看当前 WSL2 分配：运行
wsl -l -v，再进发行版执行free -h - 永久调高需编辑
%UserProfile%\.wslconfig，加入：memory=6GB swap=1GB processors=4
- 改完必须执行
wsl --shutdown再重启 Docker Desktop 才生效 - macOS 用户注意：Docker Desktop 使用 Apple Virtualization Framework，对应配置文件是
~/Library/Group Containers/group.com.docker/settings.json，但 GUI 设置已足够，一般无需手动改
docker-compose.yml 里 mem_limit 不会覆盖 WSL2 总量
很多人以为在 docker-compose.yml 里写死 mem_limit: 3g 就高枕无忧，其实这只是 cgroups 层面的软硬限制，前提是底层 WSL2 虚拟机有足够余量。如果 WSL2 总内存设成 4GB，而你定义了 3 个各占 3GB 的服务，Compose 启动时不会报错，但运行中必然冲突。
更隐蔽的问题是：某些数据库镜像（如 postgres:15）启动时会读取 /sys/fs/cgroup/memory.max 自动推导 buffer 大小，但旧版镜像或未适配镜像根本无视该路径，仍按宿主机内存算。
- 务必检查镜像文档是否声明“cgroup v2 aware”或支持
MEM_LIMIT环境变量 - 生产级部署建议显式传参，例如 PostgreSQL：
environment: - POSTGRES_SHARED_BUFFERS=1GB - POSTGRES_EFFECTIVE_CACHE_SIZE=2GB
- 避免在
mem_reservation和mem_limit之间留过大 gap，比如mem_reservation: 1g+mem_limit: 4g，容易导致调度器误判资源可用性
别信“默认 unlimited”，容器真会吃光整台 WSL2
没加 -m 的容器默认无内存硬限制，但它的进程仍运行在 WSL2 虚拟机内。一个没设限的 redis 容器，如果配置了 maxmemory 0（即不限），数据量上涨后可能直接占满 WSL2 全部内存，连 dockerd 进程都会被 OOM Killer 干掉，表现为 Docker Desktop 整体卡死、鲸鱼图标变灰。
这不是容器 bug，是资源边界没划清的必然结果。
- 本地开发建议统一加基础限制：
-m 1g --memory-swap=-1 - 对内存敏感服务（如 Elasticsearch、ClickHouse），必须同时设
--oom-kill-disable=false（默认 true），确保 OOM 时被杀而非拖垮全局 - 监控真实压力用
wsl -d docker-desktop sysctl vm.stat_refresh+cat /proc/meminfo，比看 Docker Desktop GUI 数字更准
最常被跳过的一步：调高 WSL2 内存后忘记 wsl --shutdown。它不像改 Docker Desktop 设置点一下“Apply & Restart”就完事——WSL2 实例不重启，新内存配置永远不加载。这个延迟生效机制，让很多人反复调滑块、重开软件、甚至重装 Docker Desktop，却始终卡在 2GB 陷阱里。
