developer: open process explorer是vscode唯一能直接查看各子进程（如extensionhost）真实cpu%和rss内存的原生命令，但不显示用户运行的node或python进程；需结合developer: toggle performance impact定位主线程阻塞源，及developer: start/stop extension host profile生成火焰图分析代码瓶颈。
Developer: Open Process Explorer 是唯一能直接看到进程级资源的入口
VSCode 没有“性能监控面板”这个独立界面，所谓“快速开启”，实际就是打开 Developer: Open Process Explorer。它不是仪表盘，而是实时列出所有 VSCode 子进程的表格视图——包括 main、renderer、extensionHost、shared-process 等，每行显示当前 CPU % 和 Memory (MB)。
常见错误是误以为它能监控你运行的 python script.py 或 node server.js：这些进程完全不在该列表里，除非你用了 Code Runner 并启用了进程托管（默认关闭）。
- Windows/Linux 快捷键：
Ctrl+Shift+P→ 输入Developer: Open Process Explorer - macOS 快捷键：
Cmd+Shift+P→ 同样输入该命令 - 别依赖状态栏插件（如 Resource Monitor），它只读取整个
code进程组的 RSS，无法区分哪个扩展在吃内存
Developer: Toggle Performance Impact 能暴露真正卡顿的元凶
这个命令不显示数字，但比 CPU 百分比更贴近真实体验——它记录用户操作（比如敲一个字母、保存文件）后，各扩展造成的延迟毫秒数，并在状态栏右侧显示 ⚡ 图标。点开就能看到类似 "Saving took 217ms — caused by extension 'esbenp.prettier-vscode'" 的提示。
关键点在于：它反映的是主线程阻塞时间，不是后台 CPU 占用。一个扩展可能 CPU 占用只有 2%，却因同步读大文件导致保存操作卡顿 300ms。
- 触发后需真实执行一次操作（如保存、输入、补全），才能捕获延迟来源
- 高频出现在这里的扩展，大概率在
onSave或onType回调里做了未 await 的 I/O 或正则匹配 - 它不记录历史，只显示最近一次操作的归因，需反复验证
Developer: Start/Stop Extension Host Profile 生成可分析的火焰图
当你确认某个扩展有问题，但看不出具体哪段代码拖慢时，就得靠 Developer: Start/Stop Extension Host Profile。它生成的 .cpuprofile 文件必须用 Chrome DevTools 打开（chrome://devtools → Performance 标签页 → Load），才能看清 JS 调用栈和 Self Time 分布。
注意：它只抓 Extension Host 进程的 JavaScript 执行，不包含 Node.js 底层或原生模块调用；火焰图里顶部长条点击后看底部 “Self Time”，数值高意味着函数本身耗时多，而非只是被频繁调用。
- Start → 复现卡顿动作（如打开一个 .ts 文件并触发 TypeScript 补全）→ 立即 Stop
- 生成的文件默认保存在临时目录，VSCode 会自动用浏览器打开分析页
- 展开调用栈时，重点找插件自己的方法名，如
provideCompletionItems、activate
别指望 code --status 或开发者工具 Memory 面板解决实时问题
code --status 只输出启动阶段的耗时快照，对运行中卡顿无感；Developer: Toggle Developer Tools 中的 Memory 面板虽能拍堆快照，但只能分析渲染进程（即编辑器 UI 层），对 Extension Host 内存泄漏无效——后者得靠 Developer: Open Process Explorer 观察 RSS 是否持续上涨，再配合禁用插件验证。
真正容易被忽略的是：Extension Host 进程重启不等于内存释放。右键禁用插件后，必须完整重启 VSCode，旧进程的内存才真正回收。只重载窗口，高内存条目仍会残留。
