VSCode启动慢主因是activationEvents设为"*"或"onStartupFinished"的插件冷启动时全量加载；可通过Developer: Show Running Extensions查看Activation Time定位抢跑者，并用extensions.experimental.affinity设为2实现延迟激活。
VSCode插件启动慢，不是“装多了”，而是某些插件在冷启动时就抢着加载——activationEvents设为"*"或"onStartupFinished"的插件，哪怕你只打开一个README.md，它们也已全量初始化完毕。
怎么看哪个插件在抢跑
别猜，直接看 VSCode 自己记的账：
- 启动后立刻按
Cmd+Shift+P（macOS）或Ctrl+Shift+P（Win/Linux），运行Developer: Show Running Extensions - 重点关注
Activation Time列：超过1000ms 的基本就是冷启动主力“抢跑者” - 若状态显示
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 或<5ms，说明它根本没懒加载
延迟加载比禁用更可控：用 extensions.experimental.affinity
VSCode 1.86+ 内置的 extensions.experimental.affinity 是真正绕过冷启动的机制，数字 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 “别监听这些路径的变更”。一旦漏配或路径写错，系统级文件监视器会 fallback 到低效轮询模式，导致 CPU 持续高占、保存卡顿、补全延迟：
- 必须用 glob 语法，且路径末尾带
/：正确是"**/node_modules/**": true，错误是"**/node_modules": true - 必须写在项目根目录的
.vscode/settings.json中，用户级设置无效 - 改完后必须关闭并重新打开该工作区，否则不生效
- Linux 用户额外检查：
cat /proc/sys/fs/inotify/max_user_watches，若低于524288，需提升限制
最常被忽略的其实是 activationEvents 和 files.watcherExclude 的组合效应：前者决定“谁该加载”，后者决定“谁不该被事件唤醒”。两者都配错，再轻的插件也会拖垮启动。
