直接限制WSL2内存上限并配合定期释放机制可有效缓解卡顿；需在C:\Users\用户名\下创建.wslconfig文件，配置memory=6GB（建议设为物理内存40%–60%）、swap=0、localhostForwarding=true，保存后执行wsl --shutdown重启生效。
直接限制wsl2的内存上限，再配合定期释放机制，就能有效缓解卡顿。关键不是等它“自己变好”，而是主动控制它的资源行为。
配置 .wslconfig 限制最大内存
在 Windows 用户目录（C:\Users\你的用户名\）下创建一个纯文本文件，命名为 .wslconfig（注意开头有个点，无后缀）。写入以下内容：
[wsl2] memory=6GB swap=0 localhostForwarding=true
其中 memory=6GB 是核心——建议设为物理内存的 40%–60%，16GB 内存机器设 6–8GB 较稳妥；swap=0 关闭交换分区，避免磁盘频繁读写拖慢系统；localhostForwarding=true 确保端口转发正常，不影响本地开发服务访问。
保存后，在 PowerShell 或 CMD 中运行：
wsl --shutdown
然后重新启动任意 WSL2 发行版（如 Ubuntu），配置即生效。
养成关闭 WSL2 的习惯
很多人误以为关掉终端就等于停了 WSL2，其实只要有一个发行版在运行，Vmmem 进程就会持续驻留并占用内存。正确做法是：
- 日常不用时，手动执行 wsl --shutdown
- 在 Docker Desktop 设置中，取消勾选 “Start Docker when you log in”，防止开机自启 WSL2 后台服务
- 如果只用 Docker，可考虑切换到 Docker Desktop 的 WSL2 backend + 手动启停 模式，而非常驻
检查 WSL2 内部真实内存使用
任务管理器里看到的 Vmmem 占用高 ≠ Linux 里面真有那么多进程在吃内存。进入 WSL2 终端，运行：
free -h
重点关注 available 列——这才是真正可被新进程使用的内存。如果 available 值充足（比如还有 5GB+），说明只是 Linux 缓存（buff/cache）占着没还给 Windows，属于正常现象，无需干预；如果 used 高且 available 很低，才需排查 WSL2 内部是否有内存泄漏程序（如未限制日志的 Docker 容器、无限增长的 Node.js 进程等）。
进阶：迁移 WSL2 到非系统盘
长期使用后，WSL2 的虚拟硬盘文件（ext4.vhdx）会不断膨胀，进一步加剧 C 盘压力，间接影响系统响应。可借助导出/导入方式迁移到 D 盘：
- 导出当前系统：wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu.tar
- 卸载原发行版：wsl --unregister Ubuntu-22.04
- 导入到新路径：wsl --import Ubuntu-22.04 D:\wsl\ubuntu D:\wsl-backup\ubuntu.tar --version 2
- 设置默认用户：Ubuntu2204.exe config --default-user yourname
迁移后，不仅释放 C 盘空间，还能降低系统盘 I/O 压力，对整体流畅度有明显改善。
