code --status 是最快最准的启动耗时诊断方式；重点看 Startup 总耗时（>1200ms 明显拖慢）、Extensions 中 activationTime > 300 且 isActivated: true 的扩展，以及 extensionHost 总耗时（>800ms 表示多扩展叠加拖慢主线程）。
VSCode 启动慢、卡顿，别急着重装或删扩展——code --status 就是最快最准的加载耗时诊断方式，不需要开 GUI，不依赖插件状态，5 秒内出结果。
怎么看 code --status 输出里的真实启动瓶颈
运行 code --status 后，重点盯三块：
-
Startup行：从进程启动到界面可交互的总耗时，超过 1200ms 就算明显拖慢 -
Extensions区域每行：看activationTime和isActivated两个字段组合——只有activationTime > 300且isActivated: true才算真问题；activationTime: -1是懒加载未触发，不能因此排除它 - 末尾的
extensionHost总耗时：若超 800ms，说明多个扩展叠加拖慢主线程，哪怕单个都不显眼
macOS 稳定版有时不输出完整扩展耗时，得换用 code-insiders --status。
为什么 Developer: Show Running Extensions 比 code --status 晚一步？
这个命令在 VSCode GUI 启动后才可用，看到的是“已激活且正在运行”的扩展，但会漏掉那些启动即失败、或卡在 Activating 状态的扩展。
- 它显示的
Activation Time (ms)是运行时测量值，可能受其他扩展干扰失真 - 真正要定位“谁抢了初始化控制权”，必须对比两次
code --status输出：一次禁用所有扩展（code --disable-extensions --status），一次带扩展，看哪些扩展的activationTime从 -1 突然跳到 >500 - 状态栏里点 “Extensions” 显示的进度条，只反映当前活跃操作，不是启动阶段的全貌
Developer: Open Process Explorer 能看到什么、看不到什么
这是唯一能实时看到每个扩展进程 CPU % 和内存 MB 的内置视图，但它不记录历史，也不暴露调用栈。
- 右键禁用某个扩展后，**必须重启 VSCode** 才能释放旧
Extension Host进程的内存，仅重载窗口无效 - CPU 长期 >10% 或内存持续上涨的扩展，大概率在后台轮询、监听未 dispose 的事件，或反复触发
vscode.workspace.onDidChangeConfiguration - 它不显示系统级资源（如磁盘 I/O、网络延迟），想查这些得靠
htop -T（Linux/macOS）或perfmon（Windows）
火焰图该什么时候用、怎么读关键信息
当确认某个扩展有问题，但看不出哪段代码拖慢时，才上 Developer: Start/Stop Extension Host Profile。
- 生成的
.cpuprofile必须用 Chrome DevTools 打开，不能直接在 VSCode 里看 - 在火焰图中点击顶部函数长条，重点看底部
Self Time是否异常高；展开调用栈，定位到具体插件的activate()或provideCompletionItems() - 常见陷阱：
console.time()只测 JS 层，而火焰图默认不包含 Node.js 底层调用；若怀疑原生模块问题，得换perf或py-spy
真正容易被忽略的，是采样时机——必须在工作区完全加载完毕后立刻执行 code --status，延迟几秒，activationTime 就可能变成 -1 或归零。
