WSL2内存无上限导致vmmem进程占用过高，需通过.wslconfig设memory、swap等参数并执行wsl --shutdown生效。
Windows 上 Docker Desktop 内存占用高，大概率不是 Docker Desktop 本身写得差，而是它默认把 WSL2 当“无底洞”用——vmmemWSL 进程吃掉十几 GB 内存却只跑几个轻量容器，根本原因是 WSL2 动态内存不自动收缩，且默认没设上限。
为什么 vmmemWSL 占用远高于 docker stats 显示值
WSL2 是个轻量虚拟机，vmmemWSL 进程代表它的整个内存空间；而 docker stats 只统计容器内进程的 RSS（实际物理页），不包括内核开销、page cache、tmpfs 和未释放的空闲页。两者不在同一层，直接对比会误判。
- 即使所有容器都
docker stop了，WSL2 仍可能维持高位内存，因为内核不会主动把空闲页还给 Windows -
free -h在 WSL2 终端里看到的 “available” 值常被高估，实际可回收空间需结合pageReporting=false配置判断 - 频繁构建镜像、挂载大量绑定目录（尤其是 Windows 路径）、启用
localhostforwarding=true都会加剧内存驻留
怎么用 .wslconfig 精准限制 WSL2 内存上限
不能只靠 Docker Desktop GUI 里的内存滑块——它只影响 Docker 引擎启动参数，不约束 WSL2 底层虚拟机。真正起效的是用户根目录下的 C:\Users\ 文件。
- 必须重启生效：
wsl --shutdown后再打开 Docker Desktop，否则配置不加载 - 内存值建议设为物理内存的 40%~60%，例如 32GB 主机可设
memory=12GB，太小会导致构建失败或容器 OOM - 加上
pageReporting=false才能防止内存“虚高不降”，但代价是 WSL2 不再向 Windows 主动归还空闲页（所以必须配memory硬限制） - 别漏掉
swap=2GB，否则某些 Alpine 镜像或 Java 容器在内存临界时容易触发内核 OOM Killer
docker stats 看不出问题？那就进容器查真实 RSS
docker stats 默认显示的是容器 cgroup 的 memory.current，含 page cache，容易掩盖真实泄漏。要定位具体进程，得进容器看 RSS：
- 执行
docker exec -it，重点关注 RES 列（RSS）持续上涨的进程top -o %MEM - Java 容器记得加
-XX:+UseContainerSupport，否则 JVM 会无视--memory限制，按宿主机内存分配堆 - Node.js 应用若用
node --max-old-space-size=512但容器只限 256MB，会因 GC 失败导致内存不断增长 - Python 的
gc.set_threshold()调得过大，或 pandas 读大文件未del df，也会让 RSS 滞留不降
清理完配置，别忘了关掉“隐形吃内存”的功能
有些功能开着不显眼，但长期运行会让 WSL2 内存越积越多：
- 关闭 Docker Desktop 的
Start Docker Desktop when you log in，避免每次开机就预热 WSL2 - 禁用
Use the WSL2 based engine下的Enable integration with my default WSL distro，除非你真需要从 Ubuntu 终端直接调docker命令 - 删除不用的 WSL 发行版：
wsl -l -v查看，wsl --unregister Ubuntu-22.04卸载冗余发行版（它们共用同一套 WSL2 内核，但各自占内存） - 检查是否误开了
docker buildx bake并行构建，它会拉起多个 builder 实例，每个都独占内存
最易被忽略的一点：改完 .wslconfig 后，必须手动执行 wsl --shutdown，而不是只重启 Docker Desktop 图形界面——后者不会终止 WSL2 VM 进程，配置等于白改。
