VSCode卡顿90%可由三个原生命令定位：Developer: Open Process Explorer查extensionHost下插件RSS内存（空闲>300MB）和CPU（连续10秒>25%），Developer: Toggle Performance Impact识别主线程阻塞型卡顿（如打字延迟），Developer: Start/Stop Extension Host Profile导出火焰图定位慢代码。
直接看 Extension Host 进程，别猜、别重启、别装插件——VSCode 自带的三个命令就能定位 90% 的卡顿源头。
Developer: Open Process Explorer 看谁在吃内存和 CPU
这是唯一能告诉你“哪个扩展真正在拖慢编辑器”的原生命令。它不是任务管理器里模糊的 Code Helper 进程，而是精确到 ms-python.python 或 esbenp.prettier-vscode 的子项。
- Memory 列单位是 MB，关掉所有文件后还 >300MB 的扩展大概率有问题
- CPU 看连续 10 秒是否稳定 >25%，单次峰值没意义——有些插件只在保存时爆发
- 右键可禁用，但必须执行
Developer: Restart Extension Host才释放旧内存，重载窗口无效 - 重点盯
Extension Host下的子项，不是主进程或渲染进程
Developer: Toggle Performance Impact 判定真实打字卡顿
CPU 占用低 ≠ 不卡。真正让用户觉得“输不进去字”的，往往是同步阻塞操作，比如插件在 onType 回调里没加 await 就读大文件或跑复杂正则。
- 启用后状态栏出现 ⚡ 图标，点开能看到类似
Typing took 142ms — caused by extension 'aaron-bond.better-comments' - 它反映的是主线程被锁住的时间，比 CPU 百分比更贴近“感知卡顿”
- 常见原因：插件在
activate()里同步读取配置、未设 timeout 的网络请求、反复触发vscode.workspace.onDidChangeConfiguration
Developer: Start/Stop Extension Host Profile 导出火焰图
确认某个扩展有问题后，得靠这个定位具体哪段 JS 代码拖慢。导出的 .cpuprofile 文件不能在 VSCode 里打开，必须用 Chrome DevTools。
-
Start→ 复现卡顿操作（比如打开一个.ts文件并触发补全）→ 立即Stop - 用
chrome://devtools→ Performance → ⋯ → Load profile 打开文件 - 关键看顶部长条的
Self Time，展开调用栈找activate()或provideCompletionItems()这类入口方法 - 注意：火焰图只记录 JS 执行，不包含 Node.js 底层调用；若怀疑是原生模块问题，得换
py-spy或--inspect
code --status 查启动阶段谁拖慢冷启动
命令行运行 code --status 是最轻量的诊断方式，但很多人只扫一眼就跳过。重点盯三列：
-
Startup：从进程启动到界面可交互耗时 -
Extensions下各扩展的activationTime，-1表示尚未激活（懒加载），不能直接排除 - 真正危险的是
activationTime > 300且isActivated: true；>500ms 就会明显拖慢冷启动 - macOS 上稳定版有时不输出完整扩展耗时，需用
code-insiders --status
真正容易被忽略的点是：卡顿往往不是某一个扩展“一直占 CPU”，而是多个扩展在不同时间点做同步 I/O、未加防抖的文件监听、或共享同一个语言服务器导致竞争。火焰图看不出这些协作问题，得靠 Toggle Performance Impact + 连续观察 Process Explorer 的波动节奏来交叉判断。
