Resource Saver 是 Docker Desktop 在所有容器停止且空闲30分钟后自动回收WSL2内存、降频CPU的机制；它导致容器重启时冷启动延迟，引发端口监听失败或connection refused，开发中建议禁用。
Resource Saver 是什么，为什么它有时反而让容器“掉线”
Resource Saver 不是省电模式，而是 Docker Desktop 在检测到**所有容器都已停止且持续空闲一段时间后**，自动把 WSL2 虚拟机内存大幅回收、CPU 降频的机制。它默认触发时长是 30 分钟，但这个值不能改——界面里那个滑块只控制“进入该模式前的等待时间”，不是“保持多久”，而且它不暴露给用户自定义。
问题常出在：你本地开发时习惯 docker-compose down，以为只是停服务，其实等于主动清场；5 分钟后 Resource Saver 就把 WSL2 “冻住”，再执行 docker-compose up 时，WSL2 需要冷启动加载内核、挂载文件系统，导致容器启动慢、端口监听延迟、甚至健康检查失败报 connection refused。
如果你用的是前端热重载（如 Vite/HMR）或依赖本地 API 容器的开发流，这个模式大概率会打断工作流。
如何启用/禁用 Resource Saver（Windows/macOS 通用）
打开 Docker Desktop → 右上角齿轮图标 → Settings → 左侧选 Resources → 点开 Advanced 选项卡 → 找到 Resource Saver 开关：
- 勾选即启用（默认开启）
- 取消勾选即彻底禁用（推荐开发中关闭）
- 下方滑块仅调节“空闲多久后才触发”，可选范围是
30 sec到60 min，但它对已运行中的容器无影响
改完必须点击 Apply & Restart，否则不生效。注意：这不会重启你的容器，只会重启 Docker Desktop 进程和底层 WSL2 实例。
Resource Saver 和 .wslconfig 冲突吗？
不冲突，但有优先级关系：Resource Saver 是 Docker Desktop 层的策略开关，而 .wslconfig 是 WSL2 层的硬性资源上限。即使你开了 Resource Saver，只要 .wslconfig 里写了 memory=8GB，WSL2 就绝不会突破这个天花板；反之，如果 .wslconfig 没设限，Resource Saver 也救不了你——WSL2 仍可能吃掉物理内存的 50% 并不释放。
真正起效的组合是：
- 禁用 Resource Saver（避免冷启抖动）
- 配好
.wslconfig（封死内存上限） - 再配合 Docker Desktop GUI 里的
Memory滑块（它实际会覆盖.wslconfig中同名字段，优先级更低）
也就是说：.wslconfig 是底裤，GUI 设置是外衣，Resource Saver 是个定时休眠按钮——底裤没穿好，光按按钮没用。
验证 Resource Saver 是否真的被绕过
最直接的办法是观察 WSL2 进程行为：
- Windows：打开任务管理器 → 性能页 → 查看
vmmemWSL进程的内存曲线。禁用 Resource Saver 后，它应稳定在你.wslconfig设定的memory值附近（比如 8GB），而不是从 1GB 慢慢涨到 12GB 再突然跌回 1GB - macOS：活动监视器里找
com.docker.backend和com.docker.hyperkit，内存占用应平缓，无周期性归零 - 命令行验证：在任意 WSL2 发行版里执行
free -h，Mem:行的total应始终接近你配置的值，而非随容器启停剧烈波动
别信 Docker Desktop 界面右下角显示的“Memory usage”，那个数值是 Docker Desktop 自己采样的估算，经常滞后甚至不准；free -h 才是 WSL2 内核真实上报的内存总量。
