📌 问题背景
在 WSL 2.6.0 及更高版本中，微软引入了更激进的空闲检测与内存回收机制。当用户关闭 WSL 终端窗口或短暂切离时，WSL 会在极短时间内（通常几十秒）自动挂起或回收内存。
这导致了以下痛点：
- Docker 容器频繁中断：后台运行的 Docker 服务被强杀，每次重新打开终端都需要漫长等待 Docker Engine 重新加载。
- 长耗时任务失败：编译、模型训练等后台任务在失去前台终端后被意外终止。
🔍 排查与定位过程
1. 根因定位：参考社区文章确认版本变更
在排查初期，我们参考了 CSDN 上的文章《WSL2 无故自动停止问题：完整复盘与根治方案》。该文精准指出 WSL 2.6.0+ 版本引入的空闲回收机制是导致"无故自动停止"问题的根本原因。这一关键信息帮助我们迅速排除了网络、Docker 配置或系统资源不足等干扰项，将排查焦点锁定在 WSL 自身的版本行为变更上。
2. 踩坑验证：.wslconfig 文本配置已失效
基于旧版经验，我们首先尝试在 C:\Users\<用户名>\.wslconfig 中添加 idleTimeout=-1 来禁用回收。但在 WSL 2.7.x 中，微软已彻底移除对该文本键的支持，强行添加会导致启动报错：
wsl: wsl2.idleTimeout:C:\Users\BOSINS\.wslconfig 中的键"5"未知
3. 关键发现：WSL Dashboard GUI 才是正解
在确认文本配置失效且不建议降级到 2.5.7（存在安全与数据风险）后，我们在探索 WSL 2.7+ 新增的 WSL Dashboard 时，自主发现了图形化的内存回收设置入口。这证实微软并未取消该功能，而是将其从纯文本迁移到了官方 GUI 中。
✅ 最终解决方案：使用 WSL Dashboard 调整回收策略
操作步骤
1. 打开 WSL Dashboard
在 Windows 开始菜单搜索 WSL，或通过系统托盘图标打开 WSL Dashboard。
2. 调整"自动内存回收"策略
进入 Settings (设置) -> Advanced (高级) / Resources (资源) ，找到 Auto Memory Reclaim (自动内存回收) 选项：
- Gradual (缓慢/渐进) ：👈 强烈推荐。延长空闲判定窗口至数分钟，既避免 Docker/后台任务被误杀，又保留系统内存紧张时的弹性释放能力。
- Disabled (关闭)：完全禁用回收，WSL 永久驻留内存，适合内存充足且需极致稳定性的场景。
- Default/Aggressive (默认/激进)：导致问题的元凶，建议避免使用。
3. 应用并重启 WSL
保存设置后，在 PowerShell 中执行：
powershell
wsl --shutdown🧹 收尾与清理工作
若之前尝试过其他 workaround，请清理以下残留以避免冲突：
- 清理
.wslconfig：删除C:\Users\<用户名>\.wslconfig中包含idleTimeout的行，消除启动报错。 - 清理启动项 ：删除
shell:startup文件夹中的wsl.exe -e sleep infinity快捷方式（Dashboard 设置已足够）。 - 清理 Linux 侧保活脚本：移除 crontab 心跳任务、systemd 保活服务等临时方案。
📊 方案对比总结
| 方案 | 有效性 | 推荐度 | 说明 |
|---|---|---|---|
| WSL Dashboard GUI 设置 | ✅ 完美 | ⭐⭐⭐⭐⭐ | 官方原生支持，平衡保活与内存，无需写代码。 |
| 降级至 WSL 2.5.7 | ✅ 有效 | ⭐⭐ | 需手动防自动更新，有安全与数据风险。 |
| 启动文件夹 sleep infinity | ✅ 有效 | ⭐⭐⭐ | 绕过机制的 Hack 方案，占用后台进程。 |
修改 .wslconfig |
❌ 失效 | ❌ | 2.6.0+ 版本已废弃该文本配置键。 |
💡 核心经验：
- 根因认知：WSL 2.6.0+ 的空闲回收机制是"无故停止"的根源，感谢《WSL2 无故自动停止问题：完整复盘与根治方案》一文提供的关键线索。
- 配置迁移 ：微软已将底层行为配置从
.wslconfig文本文件迁移至 WSL Dashboard GUI。未来遇到 WSL 异常，应优先检查图形界面而非手写配置文件。- 最优策略："缓慢回收 (Gradual)" 是兼顾稳定性与资源弹性的最佳选择，优于完全关闭或激进默认值。