必须显式设置--memory和--cpus限制单个容器资源，否则Docker Desktop在WSL2下无上限占用内存CPU；同时需配置wslconfig限制WSL2全局资源，并在docker-compose.yml中用deploy.resources.limits正确声明。
直接限制资源，别等卡了再查。Docker Desktop 默认不限制单个容器的 CPU 和内存，多个容器一跑，WSL2 虚拟机就可能吃掉你 80% 的物理内存，vmmem 进程飙高、风扇狂转、系统响应迟缓——这不是容器问题，是配置缺失。
怎么给每个容器加内存和 CPU 上限
启动容器时必须显式加 --memory 和 --cpus，否则它会按需疯长。比如一个 Spring Boot 服务，别让它默认占满内存：
docker run -d --memory="1g" --cpus="1.2" -p 8080:8080 my-spring-app- 数值不是拍脑袋：Java 应用建议堆内存设为容器内存上限的 60%～75%，避免 JVM 自己触发 GC 压力传导到宿主机
-
--cpus="1.2"不等于“最多用 1.2 个核”，而是“每 100ms 周期内最多用 120ms CPU 时间”，适合轻量服务；CPU 密集型任务（如 FFmpeg 转码）建议用整数，如--cpus="2" - 用
docker stats实时盯住实际占用，别只看容器日志里写的“启动成功”
为什么 Docker Desktop 在 Windows 上特别容易卡
根本原因不在 Docker，而在 WSL2。Docker Desktop 底层靠 WSL2 运行 Linux 内核，而 WSL2 默认没有内存上限，会动态吃光你能给的内存——哪怕你只开了 2 个容器，vmmem 也可能占满 12GB。
- 解决方法不是关 Docker Desktop，而是改
%USERPROFILE%\wslconfig文件（Windows 路径），加这几行： [wsl2]-
memory=4GB← 强制限制 WSL2 总内存，别留空 -
swap=1GB← 禁用 swap 或设小值，避免磁盘假死 -
processors=4← 限制可用 CPU 核心数，和宿主机保持一致 - 改完必须执行
wsl --shutdown，再重启 Docker Desktop 才生效
docker-compose.yml 里怎么写资源限制才不白配
很多人在 docker-compose.yml 里写了 mem_limit 却没效果，是因为用错了字段名或没启用 v2+ 语法。
- 必须用
deploy.resources.limits结构，且version至少为"3.8"： version: "3.8" services: api: image: my-api deploy: resources: limits: cpus: '1.5' memory: 1.5G- 注意：
mem_limit是旧版docker run参数映射，compose 不认；mem_reservation是软限制，没用 - 如果服务间有强依赖（如 DB + API），别把所有容器都设成相同资源上限——数据库通常更吃内存，API 更吃 CPU，要错开配比
容易被忽略的磁盘 I/O 和日志陷阱
卡顿不一定来自 CPU 或内存，也可能是磁盘被日志或临时文件拖垮。尤其在 Windows 下，/mnt/c/ 路径映射到 WSL2 是跨文件系统访问，I/O 延迟极高。
- 禁止把
volume挂载到C:\或D:\下的项目目录；应挂载到 WSL2 内部路径，例如/var/lib/myapp - 用
--log-opt max-size=10m --log-opt max-file=3控制容器日志大小，否则/var/lib/docker/containers/xxx/xxx-json.log一天就能涨到几个 GB - 检查
docker system df，确认Build Cache和Local Volumes没偷偷占满磁盘；定期跑docker system prune -a（注意带-a会删所有未使用镜像） - WSL2 的默认存储驱动是
ext4，但如果你从旧版本升级上来，可能残留vhdx文件，用wsl --list --verbose查看，必要时导出再重装发行版
