应使用code --inspect-extensions=9333启动vs code，再通过chrome://inspect连接extension host进程，拍摄三次堆快照（空载、操作后、关闭等待gc后），对比retained size定位detached dom和closure泄漏。
直接用 chrome://inspect 连 VS Code 扩展宿主进程
VS Code 插件（尤其是基于 WebView 的，比如 vscode-drawio）运行在独立的扩展宿主进程中，不是主窗口渲染进程。想抓到插件的真实内存行为，必须连对端口——不是 chrome://inspect 默认显示的“Visual Studio Code”主进程，而是扩展宿主（Extension Host）。
操作前先关掉所有 VS Code 实例，然后终端执行：code --inspect-extensions=9333
再打开 chrome://inspect → Configure → 添加 localhost:9333 → 刷新 → 找到 “Extension Host” 条目并点 inspect。如果没看到，说明没用 --inspect-extensions 启动，或者端口被占用了。
拍三次快照，别只拍一次
单张堆快照看不出泄漏，必须对比变化。典型节奏是：
• snapshot-0：刚连上、没打开任何 .drawio 文件、插件处于空载状态
• snapshot-1：打开 2–3 个复杂图表、切换几次标签页、触发一次导出
• snapshot-2：全部关闭后等待 30 秒，等 V8 完成 GC 再拍
右键 snapshot-2 → Compare to previous snapshot，按 Retained Size 降序排。重点筛：
• 构造函数为 Closure 且 Retained Size > 5MB 的项
• 类型为 Detached 的对象（Node.js 环境里它代表“该回收但没被回收”的强引用对象）
• 出现在 Retainers 链里的 cache、handlers、_webviewInstances 这类名字
通过 Chrome DevTools MCP 控制本机 Chrome 浏览器（保留已登录会话）。适用场景：浏览读取任意网页内容；操作 X (Twitter)：浏览动态、发推文、转帖、点赞、删帖；操作任何需登录网站（保留登录状态）；网页截图、读取页面结构、执行 JS 脚本。
看 Retainers 链，别信 Shallow Size
Shallow Size 只是对象自己占多少字节，Retained Size 才是你真正该盯的数字——它等于这个对象 + 所有它强引用的对象总内存。比如一个闭包本身才 128B，但它闭包里捕获了一个 20MB 的 Uint8Array 图像数据，Retained Size 就是 ~20MB。
展开可疑构造函数后，在右侧 Retainers 面板里找：
• 是否存在未清理的 EventEmitter.on 监听器（尤其监听了 webview.onDidDispose 却没 .off()）
• 是否有全局 Map 或 WeakMap 缓存了已销毁的 Webview 实例
• this._commitCache、context、module.exports 这些字段名是否指向你自己的插件代码路径
如果 Retainers 里全是 Node.js 内部模块（如 internal/modules/cjs/loader.js），基本可排除是你的代码问题。
避免 launch.json 自动启动带来的漏检
用 VS Code 自带的 launch.json 以 type: "pwa-node" 启动插件调试，会错过进程初始化阶段的泄漏——比如插件激活时注册的全局定时器、模块顶层缓存、require 阶段创建的闭包，这些在调试器 attach 前就已存在。
必须改用手动命令启动：node --inspect=9229 ./out/extension.js
再配 launch.json 为 attach 模式，port 对齐，localRoot 和 remoteRoot 都设为 "${workspaceFolder}"，否则快照里看不到源码映射和变量名。
另外，开发时加 --max-old-space-size=1024 能让 OOM 提前暴露，缩短定位周期——别怕崩，崩了反而说明泄漏真实存在。
