developer: open process explorer 是 vscode 唯一原生系统级进程监控工具，专用于查看主进程、renderer、gpu、shared-process 及 extensionhost 等组件资源占用，不显示用户脚本进程。
Developer: Open Process Explorer 是唯一靠谱入口
VSCode 没有“任务管理器”式系统级监控，Developer: Open Process Explorer 是原生唯一能看清各子进程资源占用的工具。它不显示你运行的 python script.py 或 node index.js，只反映 VSCode 自身组件：主进程、renderer（每个打开的窗口/WebView 一个）、GPU 进程、shared-process，以及最关键的 extensionHost（所有插件运行沙箱）。
操作路径：按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入并执行 Developer: Open Process Explorer。窗口弹出后：
- 点击 Memory 列标题排序，重点关注 extensionHost 下子项的 RSS 值（单位 MB）
- 看 Workspace 列：带具体路径（如 /home/user/my-project）的，基本锁定为当前工作区关联插件
- 右键某插件 → Reveal in Explorer，可确认它加载的是哪个 package.json 或 node_modules
extensionHost 内存高 ≠ 你代码在吃内存
很多用户误以为 extensionHost 下某个插件占了 400 MB，就是自己写的 Python 脚本在泄漏——其实不是。这个内存属于语言服务器（如 ms-python.python）、LSP 后端、格式化器（如 esbenp.prettier-vscode）或 AST 解析器，它们在后台持续解析、补全、校验你的代码，和你手动运行的脚本进程完全无关。
常见误判场景：
- 你刚保存一个大 JSON 文件，prettier 子进程瞬时飙到 500 MB：正常，几秒后应回落
- extensionHost 空闲时稳定在 600 MB+ 且不随关闭文件下降：可疑，大概率是某插件未释放缓存或监听器
- renderer 进程内存比 extensionHost 还高：别急着禁用插件，先检查是否开了 Jupyter Notebook、Storybook 预览或 Quokka —— 这些靠 Webview 实现，每个都是独立 Chromium 实例，开销天然大
禁用插件后内存不降？因为你没重启 extensionHost
右键插件选 Disable (For All Folders) 只是标记状态，旧的子进程仍驻留内存，Memory 列数字纹丝不动。真正释放必须重建进程树：
- 禁用可疑插件后，在命令面板运行
Developer: Restart Extension Host（不是 “Reload Window”） - 观察
extensionHost节点是否刷新、子项重载、Memory 值是否归零或大幅回落 - 若重启后仍高，说明问题不在该插件，而是其他扩展或 renderer 进程
注意 macOS 上若 Shared Memory 异常 >800 MB，大概率是某插件用了 SharedWorker 却没调用 terminate() —— 这类泄漏无法靠禁用解决，得关掉对应 Webview 标签页
别信 Resource Monitor 插件显示的“CPU%”
像 Resource Monitor（作者 stefanmaierhofer）这类状态栏插件，显示的 CPU 和内存数据本质是调用 ps 或 top 查整个 code 进程组的聚合值，无法区分 renderer 和 extensionHost，更不指向你当前工作区。
它的问题很实在：
- ps 在某些系统上会高估内存 20–30%，数字偏高
- 默认刷新间隔 2 秒，高负载时采样本身抬高 CPU，形成正反馈
- 没有 API 导出数据，也不能点击跳转到进程详情页
- 它甚至不能告诉你那个 12% CPU 是来自 TypeScript 语言服务器还是 Git 插件
真要定位“谁让编辑器卡”，用 Developer: Toggle Performance Impact 更准——它直接反映用户感知延迟，比如 “Save took 217ms — caused by extension 'esbenp.prettier-vscode'”，这比百分比数字有用得多
