Developer: Open Process Explorer 是排查起点，需手动触发；CodeGeeX: Start Memory Diagnostics 可自动化清空标签页、等待GC、捕获快照并识别高危扩展，但须先触发相关上下文（如GitLens需打开.git文件），再生成含webview.dispose()的修复补丁。
VSCode 里没有一键“查泄漏”的快捷键，所有真正有效的内存泄漏排查都依赖组合动作和关键命令触发，而不是单个按键——指望 Ctrl+Shift+P 里搜个“leak”就定位问题，只会浪费时间。
Developer: Open Process Explorer 是唯一必须记住的命令
这是整个排查链的起点，不看这个，后面全白忙。它直接暴露 Extension Host 进程的真实内存趋势，比任务管理器准得多。
- 按下
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS） - 输入
Developer: Open Process Explorer并回车 - 重点关注 “Memory” 列：关闭所有文件后仍卡在 150MB+ 的扩展，基本就是泄漏源
- 同时观察 “CPU” 列是否伴随周期性尖峰——这常对应未取消的
setInterval或轮询请求 - 别信“禁用插件后内存下降”：禁用只是不加载新实例，旧进程仍在吃内存；必须重启 VSCode 或手动终止 Extension Host 进程才能验证
Heap Snapshot 对比必须用 Webview DevTools，不是 VSCode 自带调试器
VSCode 的调试面板不支持堆快照对比，必须切到 Chrome DevTools 的 Memory 面板。Webview 插件（如 GitLens、vscode-drawio）泄漏几乎都卡在 Detached DOM 或 Closure 上。
- 先打开至少一个触发插件行为的文件（比如 .git 文件之于 GitLens，.drawio 文件之于 vscode-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等大对象，就是泄漏根因
CodeGeeX 的 CodeGeeX: Start Memory Diagnostics 能跳过人工等待环节
如果你装了 CodeGeeX v2.12.0+，它能把三步操作自动化：清空标签页 → 等待 150 秒让 GC 完成 → 拍快照。避免因等待不足误判“无泄漏”。
- 按
Ctrl+Shift+P输入CodeGeeX: Start Memory Diagnostics回车 - 右下角弹出浮动面板，列出内存残留 >180MB 的扩展，并标色：红色 =
Detached DOM数量 >3 且Closure Retained Size>2.1MB - 点击扩展旁的
Fix Now按钮，会自动拉取 GitHub 源码，定位activate()和deactivate()函数，生成含webview.dispose()的补丁 - 注意前提：必须已打开过相关上下文（比如 GitLens 要先打开 .git 文件），否则无法触发其泄漏路径
真正难的不是操作步骤，而是判断哪个快照差异是噪声、哪个 Closure 是真泄漏——比如 Retained Size 4.3MB 的闭包，如果只持有几个字符串，可能是正常缓存；如果持有未释放的 Webview 实例或 EventEmitter，那就是泄漏。这需要你点开闭包看引用链，而不是只盯着数字。
