code --status 输出中，Extensions 区域每行的 activationTime > 300 且 isActivated: true 才属真问题；activationTime: -1 表示懒加载未触发，不可排除；extensionHost 总耗时超 800ms 说明多扩展叠加拖慢主线程。
code --status 输出里怎么看扩展激活耗时
直接运行 code --status 是最轻量、最准的启动阶段耗时诊断方式，不需要开 GUI、不依赖插件状态。它输出的 Extensions 区域每行对应一个已激活扩展，关键字段是 activationTime 和 isActivated：
-
activationTime > 300且isActivated: true才算真问题；activationTime: -1表示懒加载，还没触发，不能因此排除 - macOS 上稳定版
code有时不输出完整扩展耗时，得用code-insiders --status - 末尾的
extensionHost总启动耗时若超800ms，说明多个扩展叠加拖慢了主线程，哪怕单个都不显眼
code --disable-extensions 是验证起点，不是最终结论
终端执行 code --disable-extensions 秒开，只能确认“问题出在扩展”，但无法告诉你哪个扩展在作祟。这一步必须紧接着做两件事：
- 启动后立刻运行
Developer: Show Running Extensions，重点看Activation Time (ms)超1000的，或状态卡在Activating/Activation failed - 再补一次
code --status（这次是带扩展的），比对两次输出中哪些扩展的activationTime突然拉长——它们大概率就是抢走控制权的元凶
code --prof-startup 生成主线程火焰图
需要定位到具体哪段 JS 代码拖慢了初始化，就得用采样式分析：code --prof-startup 启动 VSCode，操作几秒后正常退出，会在当前目录生成 cpu-*.json 文件：
- 用 Chrome 浏览器打开
chrome://tracing，拖入该文件，展开主线程（Main Thread）查看各阶段耗时 - 重点关注
workbench.desktop.main.js初始化阶段，如果某段activate()调用持续占满时间轴，基本就是那个扩展在同步读大文件或发无 timeout 网络请求 - 注意：这个参数只抓主线程，extensionHost 子进程的 CPU 占用得靠
Developer: Open Process Explorer或系统级工具（如htop -T）查
容易被忽略的兼容性细节
很多用户跑 code --status 没看到扩展耗时，不是没数据，是没在对的时间点执行：
- 必须在 VSCode 完全启动、工作区加载完毕后「立刻」执行，延迟几秒，
activationTime就可能变成-1或失真 -
extensions.experimental.affinity配置会影响扩展运行位置：设为2可强制进独立进程，便于隔离观察，但默认值1（共享 extensionHost）才是多数卡顿的真实场景 - 某些扩展（如 GitLens、ESLint）默认监听整个工作区，即使
activationTime不高，也会悄悄拉高extensionHost总耗时——尤其当项目含node_modules时
code --status、code --prof-startup 和 GUI 内命令（如 Developer: Show Running Extensions）的数据交叉印证。单独看任一输出都容易误判，比如把懒加载的 -1 当成安全，或把 Load Time 快误认为运行时不占资源。 
