Open Process Explorer显示Main、Renderer、Extension Host三进程的CPU、内存（MB）、线程数及各扩展子进程实时资源占用；Extension Host内存持续上涨且关闭文件后不回落，表明插件未正确清理Webview、事件监听器或缓存对象，需结合DevTools堆快照对比定位泄漏源。
Developer: Open Process Explorer 能看到什么
它不是“内存泄漏检测器”，而是实时进程资源仪表盘。你打开后看到的是 Main、Renderer、Extension Host 三个核心进程的 CPU 占用、内存（MB）、活跃线程数，以及每个已启用扩展的独立子进程条目。比如 vscode-drawio 或 Java Language Support 会单独列出，数值持续跳动——这才是判断“谁在偷偷吃内存”的第一手依据。
常见误判：看到某个扩展内存值偏高就立刻禁用。其实很多插件（如 vscode-drawio）在打开大型图表时临时占用 300–500MB 是正常行为；真正可疑的是——关闭所有 .drawio 文件后，该进程内存不回落，或持续缓慢爬升。
Extension Host 进程内存持续上涨怎么办
这是最典型的泄漏信号。Extension Host 是所有插件的运行沙箱，它的内存不释放，说明至少有一个插件没正确清理 Webview、事件监听器或缓存对象。
- 先执行
Developer: Reload Window—— 如果内存瞬间回落，说明是某插件初始化阶段的瞬态泄漏；如果仍缓慢上涨，大概率存在长期驻留对象 - 对比两次快照：打开
Developer: Open Process Explorer→ 记下 Extension Host 当前内存 → 等 2 分钟 → 再记一次。上涨 >50MB/分钟且无操作，基本可判定泄漏 - 临时禁用非官方扩展：运行
code --list-extensions | grep -v "^ms-" | xargs -I {} code --disable-extension {}（Linux/macOS），再观察是否缓解
Chrome DevTools Memory 标签页怎么抓泄漏
适用于基于 Webview 的插件（如 vscode-drawio、Markdown Preview Enhanced）。它能定位到 JS 层级的具体对象泄漏，比 Process Explorer 更底层。
关键操作顺序不能错：
- 先打开一个目标文件（如一个复杂
diagram.drawio） - 按
F1→ 输入Developer: Toggle Developer Tools→ 切换到Memory标签页 - 点
Take snapshot（Snapshot 1）→ 执行疑似触发泄漏的操作（如切换 tab、插入新节点、保存）→ 关闭该文件 → 等 10 秒 → 再点Take snapshot（Snapshot 2） - 选中 Snapshot 2 → 右上角下拉选
Comparison→ 看# New和# Deleted列：如果HTMLUnknownElement、DrawioEditor类实例数量不归零，就是未销毁的 Webview 实例
files.autoSave: off 不是万能解药
很多人以为关掉自动保存就能缓解内存压力，其实它只减少磁盘 I/O 触发频率，对 Extension Host 内存泄漏几乎无影响。真正起作用的是控制插件生命周期和资源回收时机。
更有效的配置组合：
-
"files.enableWatcherPolling": true—— 在 WSL2 或 NFS 挂载目录下，避免 inotify 监听风暴拖垮内存 -
"search.followSymlinks": false—— 防止搜索插件遍历符号链接形成环路，间接导致内存堆积 -
"telemetry.enabled": false—— 关闭遥测可减少后台 Node.js 进程常驻，尤其在远程开发时效果明显
记住：Process Explorer 显示的内存数字只是表象，真正的泄漏藏在插件没调用 webview.dispose()、没移除 addEventListener、或缓存了未标记为 weak 的大对象里——这些，只能靠 DevTools 的堆快照对比才能揪出来。
