vscode启动慢主因是扩展抢跑和文件监视全盘扫描；禁用gitlens、python等高耗扩展，配置files.watcherexclude排除node_modules等目录及extensions.experimental.affinity设为2，可将冷启动从4秒降至800ms。
VSCode 启动慢，八成不是机器不行，而是扩展在抢跑、文件监视器在扫全盘——禁用 GitLens、Python 等高耗时扩展，加两行 files.watcherExclude 和 extensions.experimental.affinity 配置，冷启动从 4 秒压到 800ms 很常见。
怎么快速定位拖慢启动的扩展
别靠“感觉”或“猜”，VSCode 自带两个命令就能直接看到真实瓶颈：
-
Developer: Startup Performance显示每个插件的 Start Delay（毫秒），超过 300ms 的基本就是高危项 -
Developer: Show Running Extensions实时反映 CPU % 和 Memory MB，长期 >5% CPU 或 >300MB 内存的插件（比如gitlens、dbaeumer.vscode-eslint、ms-python.python）必须优先处理 - 重点关注 Activation Events 列含
onStartup或*的扩展，它们一启动就拉起进程、扫描文件、建索引，哪怕你没开一个对应语言的文件
禁用扩展后为什么还是慢
禁用只是隐藏 UI 和命令入口，但插件的 package.json 仍被读取，监听器可能已注册。真正决定是否加载的是 activationEvents 字段：
-
"*"或"onStartup"：一启动就拉起整个插件，毫无商量余地 -
"onLanguage:typescript"：只在打开 .ts 文件时加载，安全 -
"workspaceContains:pyproject.toml"：比onLanguage:python更精准，避免单个临时 .py 文件触发 - 右键扩展 → “Extension Details” → 点齿轮图标 → “Extension Settings” → 展开 “When”，就能看到它声明的
activationEvents
为什么 files.watcherExclude 必须写对路径
files.watcherExclude 不是“隐藏文件”，而是告诉 VSCode “别监听这些路径的变更”。一旦漏配或路径写错（比如写成 "**/node_modules" 少了末尾 /**），系统级文件监视器会 fallback 到低效轮询模式，导致 CPU 持续 30%+ 占用、保存卡顿、自动补全延迟：
- 必须用 glob 语法，且路径末尾带
/**：正确是"**/node_modules/**": true，错误是"**/node_modules": true - 必须写在项目根目录的
.vscode/settings.json中，用户级设置无效 - 改完后务必关闭并重新打开该工作区，否则不生效
- Linux 用户额外检查：
cat /proc/sys/fs/inotify/max_user_watches，若低于524288，运行echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches
用 extensions.experimental.affinity 延迟加载更稳
这个配置不依赖插件自身是否适配 activationEvents，而是由编辑器强制调度加载时机。数字 2 表示“仅在首次调用其命令或打开匹配语言文件时才激活”，对老旧或未规范开发的插件特别有效：
- 适用于 ESLint、YAML、TypeScript、Python 等高频但非刚需的插件
- 配置示例：
"extensions.experimental.affinity": { "esbenp.prettier-vscode": 2, "redhat.vscode-yaml": 2, "ms-python.python": 2 } - 不要给所有插件都设
2——像ms-python.python若你每天写 Python，设为1（正常加载）反而更稳；而ms-vscode-remote.remote-ssh这类非日常插件才适合2 - 该配置对 workspace 级别也生效，可在项目根目录的
.vscode/settings.json中单独设置，避免全局一刀切
最常被忽略的是：禁用扩展后没完全退出 VSCode（macOS 用 Cmd+Q，不能只关窗口），旧插件进程可能仍在内存里跑；还有人把 /、/Users/xxx 或 C:\ 当工作区打开——这等于命令 VSCode 全盘监听。
