VSCode启动慢主因是扩展同步激活或工作区全盘扫描；禁用GitLens、ms-python.python等扩展，配置files.watcherExclude排除node_modules等目录及extensions.experimental.affinity设为2，可将冷启动从4秒降至800ms。
VSCode 启动慢，八成不是机器不行，而是扩展在启动时同步卡住，或工作区配置触发了全盘扫描——禁用 GitLens、ms-python.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或*的扩展，它们一启动就拉起进程、扫描文件、建索引，哪怕你没开一个对应语言的文件
怎么禁用扩展才真正生效
右键扩展名 → 选 Disable (Global)（全局禁用）或 Disable (Workspace)（仅当前项目禁用），别直接卸载，留着备用；禁用后必须完全退出 VSCode（macOS 用 Cmd+Q，不能只关窗口），否则旧插件进程可能仍在内存里跑。
- Remote - SSH 禁用后明显变快，说明问题不在本地，而是远程连接阻塞 UI 线程
- 禁用后重启 VSCode，再运行
Developer: Show Running Extensions确认它真没在后台跑 - 某些插件（如
GitLens）提供gitlens.activationMode设置，可设为onCommand或never跳过冷启动加载
为什么 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
怎么让插件真正“按需加载”而不是“一哄而上”
VSCode 1.86+ 内置了 extensions.experimental.affinity 机制，它不依赖插件自身是否适配 activationEvents，而是由编辑器强制调度延迟加载。数字 2 表示“仅在首次调用其命令或打开匹配语言文件时才激活”，对老旧或未规范开发的插件特别有效。
- 在
settings.json中添加类似配置："extensions.experimental.affinity": { "esbenp.prettier-vscode": 2, "redhat.vscode-yaml": 2 } - 不要给所有插件都设
2——像ms-python.python若你每天写 Python，设为1（正常加载）反而更稳；而ms-vscode-remote.remote-ssh这类非日常插件才适合2 - 该配置对 workspace 级别也生效，可在项目根目录的
.vscode/settings.json中单独设置，避免全局一刀切
最常被忽略的是：绝对不要把 /、/Users/xxx 或 C:\ 当工作区打开——这等于命令 VSCode 全盘监听，连系统日志和缓存目录都在被扫描。
