docker inspect 输出的 hostconfig.resources 是唯一可信的资源限制依据，其中 cpuquota/cpuperiod 计算得实际 cpu 核数，memorylimit（字节）反映真实内存上限，cpusetcpus 非空表示绑核生效；docker stats 仅显示实时占用，不能验证限制是否生效。
docker inspect 能看到的才是真限制
直接看 docker inspect 输出里的 HostConfig.Resources，这是唯一可信的依据。界面设置、docker-compose.yml 里写了不等于生效，可能被覆盖、拼写错误或版本不兼容。
运行命令后检查关键字段：
-
CpuQuota和CpuPeriod：比如"CpuQuota":50000,"CpuPeriod":100000表示实际限制为 0.5 核；若CpuQuota是 0，说明没设 CPU 限制 -
MemoryLimit：单位是字节，52428800 = 50MB；若为 0 或远大于你设的值（如 9223372036854771712），说明内存限制未生效 -
CpusetCpus：非空字符串表示绑核生效，如"0-1"或"0,2"
docker stats 显示的是实时占用，不是限制值
docker stats 只反映当前 CPU% 和内存使用量，它不会告诉你上限在哪。一个显示 CPU 98% 的容器，可能是被 --cpus 0.5 卡死在 50%，也可能是完全没限制、真占满了一个核——单靠这个看不出配额是否起作用。
更可靠的做法是压测验证：
- 启动带
--cpus 0.5的容器跑stress-ng --cpu 8 - 观察
docker stats中 CPU% 是否稳定在 ~50%（单核机器）或 ~100%（但不超过 0.5 核等效） - 对比无限制容器：同样压测下 CPU% 会冲到接近 100% × 物理核数
WSL2 层面的资源没调，Docker Desktop 就永远“吃不饱”
Windows 上 Docker Desktop 默认用 WSL2 后端，而 WSL2 自身有独立内存/CPU 配额。即使每个容器都设了 --memory 512m，如果 WSL2 整体被允许用光宿主机 24GB 内存，那 vmmemWSL 进程照样能把机器拖慢。
必须检查两层配置：
- 用户级：
%UserProfile%\.wslconfig文件是否存在且含有效配置，例如：memory=4GB processors=4
- 界面级：Docker Desktop → Settings → Resources → Advanced → CPUs / Memory 滑块是否已调低（该设置会覆盖 .wslconfig 的部分项）
- 验证方式：
wsl -l -v看发行版状态，然后wsl -d docker-desktop进入后执行free -h和nproc，输出应与你设的值一致
macOS 上的 resource limit 容易被 Docker Desktop 自动调高
macOS 的 Docker Desktop 有时会在后台悄悄提升资源上限，尤其在频繁构建镜像或启动多容器后。你明明在 Settings → Resources 里设了 4GB 内存，过两天再打开发现滑块自己跑到 6GB 了。
这不是 bug，是它的“自适应内存管理”策略在起作用。但对稳定性不利——它会根据最近负载动态扩容，却不会自动缩容。
解决办法很直接：
- 每次重启 Docker Desktop 前，手动把滑块拉回你设定的值，再点
Apply & Restart - 不要依赖“自动调整”，生产向开发环境必须锁定数值
- 验证时别只信 UI，仍要跑
docker inspect+docker stats组合判断
最容易被忽略的是 WSL2 或 macOS 虚拟机自身的资源上限 —— 它像一层透明玻璃，容器限制再细，撞上这层玻璃就全失效。配完容器参数，一定要回头确认底层虚拟机有没有被同步约束。
