判断插件内存泄漏最准的指标是extension host进程rss内存空载不回落，即关闭所有文件后仍稳定高于300mb且不下降；需用developer: open process explorer定位高内存插件，禁用后必须执行developer: restart extension host才有效。
直接看 Extension Host 进程 RSS 内存是否空载不回落，是判断插件内存泄漏最准的指标——不是卡顿本身，而是关闭所有文件后内存仍稳定高于 300MB 且不下降。
用 Developer: Open Process Explorer 定位高内存插件
这是第一步，也是唯一需要优先执行的操作。系统任务管理器里的 “Code Helper” 数值混着渲染进程、GPU 进程，完全不可信。
- 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入并执行Developer: Open Process Explorer - 等待几秒加载完成，点击
Memory列标题降序排序 - 展开
extensionHost节点，重点关注“空闲驻留值”：比如esbenp.prettier-vscode关掉所有文件后还稳在 420MB，fitten-code-renderer持续 >650MB 且随聊天轮次上升，基本就是泄漏源 - 别只盯一个数值——配合
CPU列看是否周期性尖峰，这常对应未节流的setInterval或未取消的fetch轮询
禁用插件后必须重启 Extension Host 才有效
禁用插件只是标记“下次不加载”，旧进程仍驻留，所有内存和监听器全在。不重启等于白禁。
- 右键可疑插件 →
Disable (For All Folders) - 立刻执行
Developer: Restart Extension Host（不是 Reload Window，后者不杀进程） - 观察“运行”按钮响应是否变快；若恢复，再逐个启用插件 + 重启，交叉验证
- 特别注意插件间联动：比如同时启用
GitLens和CodeGeeX，可能因共享WebView上下文导致泄漏放大
用 Chrome DevTools 抓堆快照确认泄漏类型
Process Explorer 只告诉你“谁吃得多”，DevTools 才能告诉你“为什么吃不完”。VSCode 自带调试器不支持堆快照对比，必须用 Chrome。
- 终端启动时加
--inspect=9229（如node --inspect=9229 app.js），或对插件用Developer: Toggle Developer Tools后访问chrome://inspect→ Configure → 添加localhost:9229 - 至少拍三次快照：
snapshot-0（空载）、snapshot-1（触发行为后）、snapshot-2（等 30 秒 GC 后） - 对比时重点筛
Retained Size高的Closure、Detached、ArrayBuffer类型；展开Retainers链，若出现this._cache、context、pendingRequests，就是泄漏根因 - 注意：Node.js 场景下
Detached不是 DOM 专属，常指被闭包持有却无法 GC 的Buffer、Timeout或EventEmitter监听器
高频泄漏插件的临时缓解配置
有些插件设计上就容易泄漏，不是你操作错，而是默认行为太激进。关掉几个开关就能立竿见影。
-
GitLens：关掉gitlens.codeLens.enabled和gitlens.currentLine.enabled，避免每行注入 DOM 节点 -
ESLint：把"eslint.run"设为"onType"而非"onSave"，防止保存瞬间全文件解析 -
Fitten Code：关掉Fitten Code: Enable Inline Suggestions、Enable History Sync、Auto Load Context Files -
vscode-drawio：每次关闭.drawio文件后，手动检查是否残留Webview实例（用Developer: Open Webview Developer Tools查Detached DOM tree）
真正难处理的从来不是单个插件泄漏，而是多个插件共用同一套缓存上下文或事件总线时，引用链交错、dispose() 顺序错乱导致的隐式泄漏——这种问题在堆快照里看不到明显根因，只能靠禁用组合+重启反复验证。
