直接运行developer: show running extensions查看activation time超1000ms或状态为activating/activation failed的插件，并用code --status验证真实激活耗时，再结合activationevents宽泛声明（如"*"、"onstartupfinished"）定位启动拖慢源。
怎么看哪个插件在启动时拖后腿
直接看 VSCode 自己记的账最准，别靠感觉猜。启动后立刻按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入并运行 Developer: Show Running Extensions。
重点盯两列：
-
Activation Time (ms)超过1000的插件，基本等于编辑器刚露头它就抢走控制权 - 状态长期卡在
Activating…或Activation failed，说明它没真正跑起来，但线程被占着不动
顺手在终端执行 code --status，输出里 Extensions 区域会列出每个插件的真实激活耗时——比 GUI 界面更细、更不可跳过。
为什么有些插件一开就“必须加载”
不是装得多，是某些插件在 package.json 里声明了太宽泛的激活条件，VSCode 只能照单全收：
-
"activationEvents": ["*"]：所有文件类型、所有操作都算触发，等于“开机即上岗” -
"activationEvents": ["onStartupFinished"]：不等你打开任何文件，编辑器 UI 刚渲染完就强制拉起 -
"activationEvents": ["onLanguage:json"]这类看似合理，但如果项目根目录有package.json，它也会冷启加载
典型代表：ms-vscode.js-debug（哪怕你从不调试）、gitlens（默认扫全仓库历史）、ms-python.python（打开纯文本也初始化 Python 环境）。
禁用 vs 延迟加载：选错等于白干
禁用插件有三种方式，效果天差地别：
-
Disable (Workspace)：只对当前文件夹生效，适合临时关掉 Vue 插件写 Python -
Disable (For All Folders)：全局禁用，重启后不加载，但保留配置和更新记录——这是最常用也最稳妥的选择 -
Uninstall：彻底删掉，但可能残留用户设置（比如esbenp.prettier-vscode卸载后保存不格式化却找不到原因）
更精细的做法是用 extensions.experimental.affinity 强制延迟加载：
"extensions.experimental.affinity": {
"esbenp.prettier-vscode": 2,
"dbaeumer.vscode-eslint": 2,
"redhat.vscode-yaml": 2
}
数字 2 表示“仅在首次打开匹配文件或手动触发命令时才加载”，不是启动就干。注意：该设置只对 VSCode 1.86+ 且支持条件激活的扩展有效，旧版无效。
验证优化是否真起效
改完配置不验证，等于没改。两个硬核手段：
- 用
code --prof-startup启动，它会生成一个cpu-profile-*.json文件，用 Chrome 打开chrome://tracing导入分析，能看到每个插件的Require Time和模块加载链路 - 对比冷启动时间：完全退出 VSCode（macOS 用
Cmd+Q，不能只关窗口），再执行code --status，看main和renderer阶段耗时是否明显下降
特别注意：files.watcherExclude 不配，再怎么调插件也没用——因为 chokidar 扫描 node_modules 或 .git 时，会直接阻塞整个插件激活流程；路径通配符必须是 "**/node_modules/**"，少一个星号或斜杠都失效。
