VSCode内存持续上涨不回落是可定位修复的泄漏，非正常老化现象；需通过清空标签页观察内存趋势、用Process Explorer查Extension Host、彻底重启进程、正确配置files.watcherExclude及启用local-process模式综合排查。
VSCode开启后内存持续上涨且不回落，基本可以确定是扩展或配置引发的泄漏，不是“用久了就卡”的正常现象——它可定位、可隔离、可修复。
怎么看是不是真泄漏，而不是单纯高内存
先别急着关插件。真正的内存泄漏有明确特征：关闭所有文件、清空编辑器标签页、等待 2–3 分钟，内存占用仍不下降，甚至继续缓慢爬升；而正常高内存使用（比如打开大项目）在关闭文件后会明显回落。
- 打开命令面板（
Ctrl+Shift+P），运行Developer: Open Process Explorer，重点看Extension Host进程的内存趋势，不是瞬时值 - 同时打开系统任务管理器（Windows）或活动监视器（macOS），对比 VSCode 各进程与系统整体内存变化是否同步
- 执行
Developer: Reload Window，如果内存立刻大幅下降，说明问题在当前会话上下文里，大概率是扩展未清理资源
禁用扩展后内存不降？你可能没真正重启进程
禁用扩展只是标记为“不加载”，旧 Extension Host 进程仍驻留并持有全部内存。必须彻底终止该进程才能验证效果。
- 禁用可疑扩展（如
GitLens、esbenp.prettier-vscode、ms-python.python）后，**必须关闭当前窗口再重新打开**，不能只靠重载 - 若仍不降，运行
Developer: Open Process Explorer找到Extension Host对应的 PID，用终端执行kill -9 [PID]（Linux/macOS）或任务管理器结束进程（Windows） - 再开新窗口，观察初始内存是否回归正常基线（通常 150–300MB）
files.watcherExclude 配置写错位置或格式，等于没配
这个配置不是“锦上添花”，而是防止 inotify 句柄耗尽、触发内核级内存泄漏的关键防线。写错位置或规则语法，VSCode 会直接忽略。
- 必须放在项目根目录的
.vscode/settings.json中，**不能只写在用户级settings.json** —— 多工作区下全局设置不生效 - 规则必须带尾部斜杠：
"**/node_modules/**"✅，"**/node_modules"❌（VSCode 会跳过） - 要同时排除
.git："**/.git/**": true，否则 GitLens 等插件会监听成千上万个松散对象文件 - 搭配
"search.exclude"是辅助项，它只影响搜索结果，不减少文件监听压力
Extension Host 内存卡在 600MB+ 不动？试试 local-process 模式
默认所有扩展跑在一个 Extension Host 进程里，一个插件泄漏，整个进程内存就锁死。VSCode 1.84+ 支持按扩展隔离进程，能有效切断传播链。
- 在项目
.vscode/settings.json中加入："extensions.experimental.affinity": { "ms-python.python": 1, "esbenp.prettier-vscode": 1 } - 数字
1表示启用独立进程，VSCode 会为这些扩展启动单独的Extension Host (local)子进程 - 配合
Developer: Show Running Extensions观察各扩展内存是否解耦——某个插件内存涨了，不再拖累其他扩展 - 注意：该功能对老旧扩展兼容性不一，若某扩展报
Extension activation failed，暂时移出该列表
最常被忽略的一点：内存泄漏往往不是单个错误导致的，而是多个小问题叠加——比如 files.watcherExclude 漏掉 .git，又没关 files.autoSave，再加上一个没 dispose() 的事件监听器，三者合力才把内存推到临界点。排查时别只盯一个环节。
