vscode 启动慢大概率是扩展抢跑所致，可用 code --disable-extensions 快速验证；若秒开则问题确在扩展，再通过 developer: show running extensions 查看 activation time、status 和 activation events 定位元凶；优先配置 extensions.experimental.affinity 延迟加载，再结合 files.watcherexclude 优化文件监听。
VSCode 启动慢，八成不是电脑不行，而是某个扩展在冷启动时抢跑——它声明了 "*" 或 "onStartupFinished" 这类宽泛的激活事件，一开就拉进程、扫文件、建索引，哪怕你只打开一个 README.md。
用 code --disable-extensions 快速确认是否是插件问题
别等加载动画转完。终端执行该命令，VSCode 会秒开，且基础语法高亮、跳转、快捷键全正常（内置能力不受影响）。如果此时流畅，而平时卡在 “Activating Extensions” 阶段，那问题 100% 出在扩展上。
这个命令不改任何设置，也不卸载插件，只是临时屏蔽，比手动禁用快得多也更干净。
- 验证后不用关掉窗口，直接按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入并运行Developer: Show Running Extensions - 注意：某些插件（如
ms-python.python）即使没打开 Python 文件也会激活，所以不能靠“我没写 Python”来排除
看 Developer: Show Running Extensions 找出真正在拖慢的插件
这个面板不是罗列“已启用”，而是显示当前真正在后台干活的扩展，重点关注三列：
-
Activation Time (ms)超过 1000 的，基本等于在编辑器刚露头时就抢走控制权；超过 1500 的（比如旧版ms-python.python或eamodio.gitlens）大概率是元凶 -
Status长期显示Activating或空白，说明它卡住了但没报错，还在后台占着线程 -
Activation Events是关键线索：右键插件 →Extension Details→ 看 “When” 字段，值为"*"、"onStartupFinished"或"onLanguage:json"这种不加限制的匹配，就是默认就干重活的信号
别急着卸载，先调配置或设延迟加载
很多“重”是默认太莽，不是插件本身不行。比如 gitlens 默认全仓库扫描历史，ms-vscode.js（2026年9月1日）默认一启就拉起语言服务。
- 在用户级
settings.json（不是工作区）中添加："extensions.experimental.affinity": {<br> "ms-python.python": 2,<br> "esbenp.prettier-vscode": 2,<br> "eamodio.gitlens": 2<br>}
数字2表示“仅在关联文件打开或命令触发时加载”，不是启动即载入 - 该配置对旧版扩展无效，需确认扩展页的
Activation Events字段是否支持条件触发（2026 年 5 月资料确认主流扩展已适配） - 若仍卡顿，可在项目根目录的
.vscode/settings.json中补上："files.watcherExclude": {<br> "**/node_modules/**": true,<br> "**/dist/**": true,<br> "**/.git/**": true,<br> "**/build/**": true<br>}
容易被忽略的几个点
有些问题不会立刻暴露，但会在多项目切换、远程开发或升级后集中爆发：
-
Settings Sync开启状态下，首次启动会拉取远程配置并比对本地状态；国内网络下若 GitHub 同步服务响应慢，就会卡住不动，且控制台无明显报错 - Linux 用户要检查
/proc/sys/fs/inotify/max_user_watches，低于524288就得调，否则node_modules一多，监听直接失效 - macOS 上不要把用户主目录或磁盘根目录作为工作区打开——这等于让 VSCode 扫描整个系统
- Remote - SSH 卡顿，往往不是本地问题，而是远程连接阻塞 UI 线程；禁用后必须完全退出 VSCode（macOS 用
Cmd+Q），否则缓存会掩盖效果
