关闭Docker Desktop的Resource Saver功能可直接解决WSL2命令卡死、df无响应、ps aux挂住等问题，因其暂停/恢复WSL2实例的逻辑缺陷会导致内核状态异常；需在Docker Desktop设置中取消勾选“Enable Resource Saver”并点击Apply & Restart生效。
直接关掉 Resource Saver 就能解决 WSL2 命令卡死、df 无响应、ps aux 挂住等问题。这不是“可选项”，而是当前 Docker Desktop（2024 年后多个版本）与 WSL2 协同时已知的稳定缺陷——它在空闲时暂停 WSL2 实例，但恢复逻辑有 bug，导致内核状态异常，系统命令无法正常返回。
Resource Saver 是什么，为什么它会导致命令卡住
Resource Saver 是 Docker Desktop 内置的节能机制，设计目标是当检测到 Docker 无活跃容器或构建任务时，自动暂停底层 WSL2 发行版（比如 docker-desktop-data），以释放内存和 CPU。但它暂停的不是“空闲进程”，而是整个 Linux 内核上下文；恢复时若遇到 I/O 等待未超时、挂起的 socket 或 page cache 锁竞争，就会卡在系统调用层面——表现为 df、ps、ss 等基础命令长时间无输出，甚至 SSH 连接失败。
关键点：
- 该问题只在 Docker Desktop 启动后一段时间才出现，刚启动时正常
- 关闭 Docker Desktop 后，WSL2 命令立刻恢复正常，说明问题根因不在 WSL2 本身
- 即使你没运行任何容器，只要 Docker Desktop 在后台运行且启用了 Resource Saver，就可能触发
关闭 Resource Saver 的操作路径（Windows + WSL2 后端）
这是最直接有效的修复方式，无需改配置文件、不依赖重启 WSL2 发行版：
- 右键点击任务栏右下角的
Docker Desktop图标（?） - 选择 Settings → 左侧导航栏点 Resources
- 找到开关项：Enable Resource Saver，把它取消勾选
- 点击右下角 Apply & Restart —— 注意：必须点这个按钮才会真正关闭并重载 WSL2 状态
完成后，vmmemWSL 进程不再反复启停，df 和 ps aux 类命令会恢复毫秒级响应。
为什么不能只靠 .wslconfig 或 Docker Desktop 界面滑块
很多人误以为调低 Docker Desktop 设置里的内存/CPU 滑块，或者在 %UserProfile%\.wslconfig 里加 memory=4GB 就能治本——其实不能：
-
.wslconfig控制的是 WSL2 全局资源上限，不影响 Resource Saver 的暂停/恢复行为 - Docker Desktop 界面中的 memory/cpu 滑块只限制
docker-desktop和docker-desktop-data这两个发行版的初始配额，不干预 Resource Saver 的调度逻辑 - Resource Saver 是独立于资源配额的“生命周期管理器”，它会在满足条件时强行 suspend 整个 WSL2 实例，此时哪怕你只分配了 2GB 内存，也会卡住
换句话说：.wslconfig 是“最多能吃多少”，Resource Saver 是“吃完要不要打个盹”——而这个“盹”目前会打到半梦半醒、卡在 syscall 里出不来。
关掉之后要注意什么
关闭 Resource Saver 后，WSL2 实例将保持常驻运行，vmmemWSL 进程会持续占用一定内存（通常 1–2GB 起步），但这属于正常缓存行为，不是泄漏。如果你发现它持续涨到 6GB+ 且不回落，那可能是：
- 容器内应用存在内存泄漏（如 Node.js 未释放引用、Java 堆未 GC）
- WSL2 自身内核版本过旧（执行
wsl --update升级到最新版可缓解 page cache 回收延迟） - 磁盘空间不足导致 ext4.vhdx 扩展失败，触发内核异常重试
真正要警惕的不是内存数字本身，而是命令响应是否稳定、free -h 中的 available 是否持续低于 500MB、以及有没有大量 D 状态进程（不可中断睡眠）。
