code --status是诊断VS Code启动性能的第一真相入口，输出中Extensions区域activationTime > 300且isActivated: true为真问题，activationTime: -1表示懒加载未触发不可排除；extensionHost总耗时超800ms说明多扩展叠加拖垮主线程。
直接跑 code --status，比开 GUI 查任何面板都快、都准——它不依赖插件状态，也不受渲染线程卡顿影响，是诊断启动阶段性能的第一真相入口。
怎么看 code --status 输出里的真问题
执行后重点盯 Extensions 区域每行的两个字段：activationTime 和 isActivated：
-
activationTime: -1表示懒加载未触发，不能因此排除；它只是还没被用到，不代表安全 -
activationTime > 300且isActivated: true才算真正拖慢冷启动——比如ms-python.python激活耗时 482ms，就是高危信号 - 末尾的
extensionHost总耗时若超 800ms，说明多个扩展叠加已拖垮主线程，哪怕单个都不显眼 - macOS 稳定版有时输出不全，必须改用
code-insiders --status
为什么 code --disable-extensions 只是起点，不是答案
终端执行 code --disable-extensions 秒开，只能确认“问题出在扩展”，但无法定位具体哪个。接下来必须做两件事：
- 启动后立刻运行命令
Developer: Show Running Extensions，重点筛Activation Time (ms)超 1000 的，或状态卡在Activating/Activation failed - 再补一次带扩展的
code --status，比对两次输出中哪些扩展的activationTime从 -1 突然跳到几百甚至上千——它们大概率抢走了控制权 - 别信“已禁用”就万事大吉：某些扩展（如 GitLens）会在首次激活后缓存大量数据，重启前需手动清空
~/.vscode/extensions/xxx/storage
怎么抓住那个在后台偷偷吃 CPU 的扩展
很多卡顿不是启动慢，而是编辑过程中突然转圈、补全延迟——这往往来自某扩展在 onType 或 onSave 里做了同步阻塞操作：
- 执行
Developer: Toggle Performance Impact，状态栏出现 ⚡ 图标，点开就能看到“Typing took 142ms — caused by extension 'aaron-bond.better-comments'”这类真实用户感知延迟 - 配合
Developer: Open Process Explorer查 Extension Host 下子进程：CPU 长期 >10% 或内存持续上涨（尤其 >200MB），基本就是它在后台轮询或解析 - 右键禁用后，必须重启 VSCode 才能真正释放旧 Extension Host 进程——仅重载窗口无效
- 某些扩展（如 ESLint、Prettier）默认 onType 实时检查，改成
"eslint.run": "onSave"可立竿见影
最常被忽略的是 files.watcherExclude 配置：哪怕只漏掉一个 "**/node_modules/**"，chokidar 就会监听成千上万个文件变更，让所有扩展一起陪跑。路径通配符必须双星号开头，写成 "*/node_modules/*" 或漏掉末尾 /** 都等于没配。
