vmmem进程内存不释放是WSL2设计行为而非泄漏：它不会主动归还空闲内存给Windows，需执行wsl --shutdown才能彻底清理；.wslconfig中必须同时设置memory和swap=0，且VSCode的Node.js进程才是内存主要占用者。
为什么 vmmem 进程内存不释放？
这不是内存泄漏，而是 WSL2 的设计行为：vmmem 代表整个 WSL2 虚拟机的内存映像，它**不会主动归还空闲内存给 Windows**，哪怕你已退出所有终端、关掉 VSCode、甚至停止所有 Linux 进程。系统默认策略是“用过即留”，避免频繁分配/回收开销——但代价是长期运行后内存越积越多。
典型表现：执行 wsl --shutdown 后 vmmem 立刻消失；但只关 VSCode 或只退出 bash，vmmem 占用纹丝不动。这和 Linux 的 free -h 显示“可用内存低”不矛盾——WSL2 内核确实还持有这些页，只是没告诉 Windows 可以回收。
.wslconfig 中 memory 和 swap=0 必须配对使用
单独设 memory=4GB 不足以阻止内存爬升，因为 WSL2 在接近上限时会启用交换（swap），而 swap 文件本身又会持续占用磁盘缓存 + 内存映射，加剧 vmmem 增长。
实操建议：
- 务必同时设置
swap=0，彻底禁用交换机制 -
memory值建议设为物理内存的 50%～60%，例如 16GB 主机设memory=8GB，留出余量给 Windows 和 VSCode 主进程 - 不要设得太低（如
memory=2GB），否则 Node.js 编译或 npm install 容易 OOM 中断
VSCode Remote-WSL 启动时触发的 Node.js 进程才是真凶
真正吃内存的不是 WSL2 内核本身，而是 VSCode 在 WSL2 中拉起的 node 进程群：vscode-server、language server、file watcher、extension host。它们长期驻留且不随编辑器窗口关闭而退出。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
关键控制点：
- 每次重启 VSCode 后，必须手动执行
wsl --shutdown才能清理这些残留 Node 进程 - 在 WSL2 终端中运行
ps aux | grep node，常能看到多个/usr/share/code-server/bin/code-server或/home/xxx/.vscode-server/bin/...进程挂着 -
killall node临时有效，但下次打开 VSCode 又会重建——所以不能依赖 kill，必须靠wsl --shutdown彻底重置
别信“自动回收”，wsl --shutdown 是唯一可靠手段
网上有些方案建议改内核参数或调 /proc/sys/vm/vfs_cache_pressure，实测无效。WSL2 的内存回收逻辑由 Hyper-V 驱动硬编码控制，用户态无权干预。
真正有效的日常操作节奏：
- 开发结束时，先关闭所有 VSCode 窗口
- 打开 PowerShell 或 CMD，执行
wsl --shutdown - 如果常用 Docker Desktop，注意它也会启动独立 WSL2 实例，需额外执行
wsl -t docker-desktop关停 - 下次启动 VSCode 时，它会自动拉起全新轻量实例，
vmmem从 200MB 起步，而非继承上次的 6GB
这个 shutdown 步骤无法跳过，也没有后台服务能替代它——它不是“重启”，而是销毁整个 VM 实例。省略这一步，所有配置都只是延缓爆表，不是根治。
