VSCode内存持续上涨且关闭所有文件后2–3分钟不回落即为扩展泄漏，非自然老化；需清空标签页观察内存趋势、用Process Explorer查Extension Host真实内存、Reload Window验证会话问题、抓Heap Snapshot对比Detached DOM和Closure、禁用后必须彻底重启进程而非仅重载。
VSCode内存持续上涨且关闭所有文件后2–3分钟仍不回落，基本就是扩展泄漏，不是“用久了就卡”的自然现象——它可定位、可隔离、可修复。
怎么看是不是真泄漏，而不是单纯高内存
别急着关插件。真正的泄漏有明确特征：清空所有标签页 → 等待 2–3 分钟 → 内存占用仍不下降，甚至缓慢爬升。而正常高内存（比如刚打开一个大项目）在关闭文件后会明显回落。
关键验证动作：Developer: Reload Window。如果内存立刻大幅下降，说明问题在当前会话上下文里，大概率是扩展未清理资源；如果 reload 后内存纹丝不动，就得往下查进程级问题。
用Developer: Open Process Explorer查Extension Host真实内存趋势
这是最轻量但最关键的一步：它直接显示 Extension Host 进程的真实内存趋势，比系统任务管理器更准——排除了渲染进程、GPU 进程等干扰项。
- 重点关注
Memory列数值持续上涨、且空载时仍维持 150MB+ 的扩展 - 若某扩展在关闭所有文件后内存卡在 600MB+ 不动，基本可判定其
dispose()逻辑失效 - 同时看
CPU列是否伴随周期性尖峰，这常对应未节流的定时器或未取消的fetch轮询
抓Heap Snapshot对比Detached DOM和Closure
VSCode 的 Webview 插件（如 vscode-drawio、GitLens、ms-toolsai.jupyter）泄漏对象，往往卡在“已从 DOM 移除但 JS 仍持有引用”的状态。
- 打开相关文件（如 3 个
.drawio），执行Developer: Open Webview Developer Tools→Memory→Take heap snapshot，存为snapshot-1.heapsnapshot - 关闭所有相关文件，等待 30 秒（给 GC 时间），再拍一次存为
snapshot-2.heapsnapshot - 在
Comparison视图中筛选Detached DOM tree：若数量 > 0，且新增类型含HTMLDivElement或CanvasRenderingContext2D，说明 Webview 实例没销毁 - 检查
Closure类型下新增函数的Retained Size：若 > 2MB 且闭包内引用了this._cache、context等大对象，就是泄漏根因
禁用扩展后内存不降？你可能没真正重启进程
禁用扩展只是标记为“不加载”，旧 Extension Host 进程仍驻留并持有全部内存。必须彻底终止该进程才能验证效果。
- 禁用可疑扩展（如
GitLens、esbenp.prettier-vscode、ms-python.python）后，必须关闭当前窗口再重新打开，不能只靠重载 - 若仍不降，运行
Developer: Open Process Explorer找到Extension Host对应的 PID，用终端执行kill -9 [PID]（Linux/macOS）或任务管理器结束进程（Windows） - 再开新窗口，观察初始内存是否回归正常基线（通常 150–300MB）
容易被忽略的一点：很多用户以为“禁用 + Reload Window”就等于重启，其实 Extension Host 进程仍在后台运行，所有泄漏对象都还活着——必须杀进程或彻底关窗再开，否则一切分析都是白忙。
