open process explorer 是 vscode 原生进程树视图，直接映射 electron 子进程层级，extension host 下每个子项对应一个已激活插件，显示其 rss 内存（mb）和采样 cpu %，刷新间隔约 2 秒。
Developer: Open Process Explorer 是查插件资源占用的唯一可靠入口
它不是“任务管理器”，而是 VSCode 原生进程树视图，直接映射 Electron 子进程层级。Extension Host 下每个子项对应一个已激活插件，旁边数字是 RSS 内存（MB）和采样 CPU %，刷新间隔约 2 秒。
常见错误现象：看到 extensionHost 进程内存飙到 800MB，就以为是“所有插件合起来吃这么多”——其实那只是宿主进程自身开销，真正泄漏源藏在它下面的子项里。比如 ms-python.python 占 420MB，esbenp.prettier-vscode 占 180MB，加起来才接近总数。
- 右键禁用插件后，必须执行
Developer: Restart Extension Host才释放内存，仅重载窗口无效 - 空闲状态下某插件 RSS 持续 >300MB 且不回落，基本可判定存在未清理的缓存或监听器
-
shared-process异常高内存（尤其 macOS）往往指向 sharedWorker 泄漏，不是插件问题而是 VSCode 底层机制
Developer: Show Running Extensions 看的是真实运行时影响，不是启用列表
这个命令列出的插件，全是当前正在响应事件、持有句柄、执行回调的活跃实例。它比设置里的“已启用”列表准得多，能过滤掉那些只装着但根本没触发的插件。
关键字段不是“名字”，而是 Activation Time 和 Runtime Impact。前者超过 500ms 的插件，大概率拖慢启动；后者长期 >15% 的，说明它在后台高频轮询或同步阻塞主线程。
-
Activation Events列含onStartup或*的插件（如GitLens、ESLint）优先排查 - 如果某插件显示
Not activated，它此刻对性能零影响，不用管 - 禁用后仍出现在列表里？说明它被其他插件依赖或通过
extensionKind设为 workspace 级别，需检查extensions/exploration
Performance 面板必须手动录制才能看内存曲线
打开 Developer: Toggle Developer Tools → 切到 Performance 标签页，界面默认空白。不点右上角 ● 录制按钮，就永远看不到任何数据——这是最常被卡住的第一步。
录制期间做典型操作（如保存、切换文件、输入），停止后底部 Memory 面板才会出现时间线。纵轴单位是 MB，高峰对应你刚做的动作，但要注意区分 Renderer（编辑器 UI）和 Extension Host（插件）的堆增长。
- 内存持续单向上涨，停顿后不回落 → 典型泄漏信号
- 峰值后快速回落但基线抬高 → 插件缓存策略激进，未必是 bug
- Mac 上 Shared Memory 异常高，大概率是某插件用了 Electron sharedWorker 但没调
terminate()
别信状态栏里“CPU 12%”这种数字
像 Resource Monitor 这类扩展显示的 CPU%，本质是调用 ps 查整个 code 进程组，无法拆分到 Extension Host 或单个插件。更糟的是，它自己每 2 秒轮询一次，高负载时反而推高 CPU，形成正反馈。
真正想定位“哪个插件让打字卡”，得用 Developer: Toggle Performance Impact。它不显示百分比，而是在状态栏亮 ⚡，点开告诉你 “Saving took 217ms — caused by extension 'bradlc.vscode-tailwindcss'”。这才是用户感知延迟的真实来源。
- 该命令反映的是主线程阻塞耗时，不是后台线程 CPU 占用
- 若某插件频繁出现在这里，说明它在
onSave里做了同步 I/O 或大数组遍历 - 数值超过 16ms 就可能掉帧，连续出现 >50ms 基本等于编辑器“假死”
files.watcherExclude 没配 **/node_modules/**，导致几万文件持续触发 onDidChangeFileSystem 回调，再轻量的插件也会被拖垮。
