VSCode启动慢主因是插件冷启动全量加载，可通过Developer: Show Running Extensions查看Activation Time定位抢跑者，并用extensions.experimental.affinity设为2延迟激活，配合files.watcherExclude精准排除监听目录。
VSCode 启动慢，大概率不是“装多了”，而是个别插件在冷启动时就全量加载——activationEvents 设为 "*" 或 "onStartupFinished" 的插件，哪怕你只打开一个 README.md，它已经把语言服务、网络请求、文件扫描全干完了。
怎么看哪个插件在抢跑
别猜，直接看 VSCode 自己记的账：
- 启动后立刻按
Cmd+Shift+P（macOS）或Ctrl+Shift+P（Win/Linux），运行Developer: Show Running Extensions - 重点关注
Activation Time (ms)列：超过1000的基本就是冷启动主力“抢跑者” - 状态显示
activated by another extension？说明它是被连带唤醒的，得顺藤摸瓜查源头 - 右键插件 →
Extension Details→ 点齿轮图标 → 展开When字段，就能看到它声明的activationEvents
禁用不等于不加载，关键看 activationEvents
禁用插件只是隐藏 UI 和命令入口，package.json 仍会被读取，监听器可能早已注册。真正决定是否加载的是 activationEvents 字段：
-
"*"或"onStartup"：一启动就拉起全部逻辑，毫无商量余地 -
"onLanguage:typescript"：只在打开.ts文件时加载，安全 -
"workspaceContains:pyproject.toml"：比onLanguage:python更精准，避免单个临时.py文件触发 - 验证方式：运行
Developer: Show Running Extensions，若某插件Activation Time是0ms 或ms，说明它根本没懒加载
延迟加载比禁用更可控：用 extensions.experimental.affinity
extensions.experimental.affinity 是 VSCode 1.86+ 内置的绕过冷启动机制，数字 2 表示“仅在首次调用其命令或打开匹配语言文件时才激活”：
- 对老旧、未规范适配
activationEvents的插件特别有效，比如ms-python.python、esbenp.prettier-vscode - 必须写进
settings.json（全局或工作区），不能靠 UI 设置 - 示例配置：
{
"extensions.experimental.affinity": {
"ms-python.python": 2,
"esbenp.prettier-vscode": 2,
"redhat.vscode-yaml": 2
}
}- 不要给所有插件都设
2——像 Python 扩展若你每天写 Python，设为1（正常加载）反而更稳；而Remote - SSH这类非日常插件才适合2
files.watcherExclude 配错一个斜杠，监听就退化成轮询
files.watcherExclude 不配，插件再轻也白搭。VSCode 的文件监听器（chokidar）一旦被 node_modules、.git 这类目录拖住，所有插件的触发逻辑都会变慢——因为它们都依赖这些事件：
- 路径必须严格匹配，
"**/node_modules/**"和"**/node_modules"效果不同，后者可能不生效 - 推荐写法（注意结尾斜杠和双星号）：
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/objects/**": true
}- 配完需关闭并重新打开工作区才生效，改完立刻执行
code --status看Files区域监听数量是否明显下降
真正卡住启动的，往往不是插件数量，而是某个插件在错误时机做了错误的事——比如在 onStartup 里同步读大文件、发起无超时网络请求，或者监听了整个 node_modules。优化的关键不是删插件，而是切断它的冷启动路径。
