vscode启动慢八成因插件冷启动抢跑；通过developer: show running extensions查看activationevents为*或onstartupfinished的插件，禁用（for all folders）或设extensions.experimental.affinity为2实现延迟加载，并用code --prof-startup验证优化效果。
VSCode 启动慢，八成是因为插件在“假装待命”——它们声明了 "*" 或 "onStartupFinished" 这类宽泛的 activationEvents，结果一开编辑器就全被拉起来，哪怕你只写个 Markdown。
怎么确认哪些插件在冷启动时抢跑
别猜，直接看 VSCode 自己报的账：
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），运行Developer: Show Running Extensions - 列表里标为 “Active” 且状态栏没显示任何触发动作（比如没打开 JS 文件、没执行命令）的，基本就是冷启加载的“嫌疑插件”
- 右键 → “Extension Details”，点右上角齿轮图标 → “Extension Settings”，再展开 “When” 字段，就能看到它声明的
activationEvents值 - 如果值是
"*"、"onStartupFinished"或"onLanguage:json"这种不加限制的匹配，那它大概率在拖慢你第一次打开的速度
禁用方式选错，等于白操作
VSCode 提供三种禁用粒度，效果完全不同：
-
Disable (Workspace)：只对当前文件夹生效，适合 Python 项目里临时关掉 Vue 插件 -
Disable (For All Folders)：全局禁用，重启后不会加载，但保留配置和更新记录——这是最常用也最稳妥的选择 -
Uninstall：彻底删掉，但某些插件（如esbenp.prettier-vscode）卸载后可能残留用户设置，导致保存时不格式化却找不到原因
特别注意：Disable (For All Folders) 后，插件的 package.json 里 activationEvents 还在，只是 VSCode 不响应它——很多人误以为“禁用了就等于没这回事”，结果优化无效。
延迟加载（affinity=2）比禁用更细粒度
VSCode 1.86+ 支持强制让指定插件跳过初始激活，仅在首次调用其功能时才加载。这招对 ESLint、YAML、TypeScript 等高频但非刚需的插件特别有效：
- 打开
settings.json（命令面板输入Preferences: Open Settings (JSON)） - 添加如下配置：
"extensions.experimental.affinity": {
"esbenp.prettier-vscode": 2,
"redhat.vscode-yaml": 2,
"ms-python.python": 2
}
其中数字 2 表示“延迟加载”，VSCode 将跳过这些插件的初始激活。注意：这个设置不改变插件自身逻辑，也不影响它后续被正确触发——只是把加载时机从“开机就干”变成“你真要用我才动”。
验证优化是否真的起效
别信“好像快了”，得用 VSCode 自带的 profiler 抓真实耗时：
- 终端执行
code --prof-startup（macOS/Linux）或命令行运行code --prof-startup（Windows） - 启动完成后，会在临时目录生成
cpu-profile-*.json文件 - 用 Chrome 打开
chrome://tracing，导入该文件，重点关注 “activate” 和 “require” 阶段的耗时堆叠 - 若某个插件在
activate阶段占了 800ms 以上，而你已把它设为affinity: 2或禁用，却仍出现在这里，说明配置没生效或路径不对
真正容易被忽略的是：插件是否被多个工作区/远程连接重复加载；以及 remote.extensionKind 设置是否与本地 affinity 冲突——这两处一旦出错，延迟加载就形同虚设。
