code --status 是诊断 VSCode 启动慢最准最轻量的方法，重点关注 activationTime > 300 且 isActivated: true 的扩展、extensionHost 超 800ms、Startup 超 2s 三处，配合 --prof-startup 和 --trace-renderer 生成完整火焰图定位瓶颈。
直接用 code --status 就能看到启动各阶段耗时，它比图形界面里的 Startup Performance 更准、更轻量，且不依赖扩展是否已激活。
怎么看 code --status 输出里真有问题的扩展
执行后重点盯三处：
-
activationTime值大于 300 且isActivated: true的扩展——这才是实际拖慢启动的元凶；activationTime: -1表示还没触发懒加载，不能因此排除 - 末尾的
extensionHost总耗时若超 800ms，说明多个扩展叠加已明显影响主线程，哪怕单个都不显眼 -
Startup行显示从进程启动到界面可交互的总时间，超过 2s 就该排查了
macOS 稳定版有时输出不全，此时换用 code-insiders --status。
code --prof-startup 和 --trace-renderer 必须一起用
只加 --prof-startup 只能捕获主线程（如 workbench.desktop.main.js 初始化），但漏掉渲染进程的关键路径。必须补上 --trace-renderer 才能生成完整 .trace 文件。
- 必须先彻底关闭所有 VSCode 实例（包括托盘后台进程），否则参数不生效
- 日志默认存在
$HOME/.config/Code/logs/（Linux/macOS）或%APPDATA%\Code\logs\（Windows），按日期建子目录 - 用 Chrome 打开
chrome://tracing，拖入.trace文件，展开Main Thread和Renderer查瓶颈
code --disable-extensions 是起点，不是终点
它只能帮你确认“问题出在扩展”，但无法指出具体是哪个。
- 如果禁用后秒开，下一步必须立刻运行
Developer: Show Running Extensions，看 Activation Time (ms) 超 1000 的扩展 - 再补一次带扩展的
code --status，和前一次对比，哪些扩展的activationTime突然拉长，大概率就是它们 - 某些扩展（如 GitLens、ESLint）默认监听整个工作区，文件一多就同步阻塞，这类问题在
--prof-startup火焰图里会表现为某段activate()占满时间轴
很多人卡在第一步：以为 code --status 没数据就是没瓶颈，其实是没在工作区完全加载完毕后「立刻」执行——延迟几秒，activationTime 就可能变成 -1 或失真。
