VSCode冷启动变慢主因是ms-vscode.js-debug等四个内置扩展默认启用并同步激活；禁用它们或配置extensions.experimental.affinity可显著提速。
哪些内置扩展最常拖慢 VSCode 冷启动
VSCode 启动卡在“Activating Extensions”阶段，八成以上是几个 ms-vscode. 开头的内置扩展在后台预热——它们不显示在市场页，却默认启用、声明 onStartup 或通配符 * 激活事件，且从不提示你它正在加载。
重点排查以下四个：
-
ms-vscode.js-debug：即使你从不调试 JS，它也会初始化完整调试服务 -
ms-vscode.vscode-typescript-next：无tsconfig.json也加载 TS 语言服务器，吃内存且不可跳过 -
ms-vscode.references-view：随编辑器启动即初始化，但多数人只用右键“查找所有引用”，极少打开侧边栏 -
ms-vscode.test-explorer：只要工作区含package.json或jest.config.js就自动激活，纯 Python/Markdown 项目完全无用
它们在 Extensions: Show Installed Extensions 中搜 @builtin 即可列出。禁用方式和第三方扩展一致，但注意：ms-vscode.vscode-typescript-next 禁用后，JS/TS 文件将丢失跳转、补全、语义高亮——前端或 Node 开发者慎动。
如何快速定位高耗时扩展而不靠猜
别逐个禁用试错。直接用 VSCode 自带的诊断工具，三步锁定元凶：
- 启动后立刻按
Cmd+Shift+P（macOS）或Ctrl+Shift+P（Windows/Linux），输入并执行Developer: Startup Performance - 看报告中 “Extension Activation” 列表，重点关注
activation time> 300ms 的扩展（比如某次实测GitLens达 1240ms） - 再运行
Developer: Show Running Extensions，观察哪些扩展长期显示 “Activating…” 或 CPU 占用持续高于 5%
补充验证方式：终端执行 code --status，输出里 Extensions 区域会明确标出每个扩展的 activated 状态和耗时。比 GUI 更准，尤其适合脚本化排查。
第三方扩展里哪些是“高危常驻型”
这类扩展不是启动慢的唯一原因，但一旦启用就几乎永不退出，持续监听文件、解析 AST 或轮询网络：
-
ESLint：默认校验所有.js/.ts文件，若未配置eslint.validate为仅当前文件，会在打开大项目时同步扫描整个src/ -
Prettier：开启formatOnSave且项目含大量配置文件（如.prettierrc嵌套多层）时，每次保存都触发全量解析 -
Auto Import：每敲一个字母都尝试 AST 分析，src/下超 500 个 TS 文件时，输入延迟肉眼可见 -
Remote - SSH：不是插件本身慢，而是连接远端失败时阻塞 UI 线程，表现为“界面假死”，日志里却无报错
它们的问题往往不出现在启动瞬间，而是在后续操作中持续拖累响应——所以必须结合 Developer: Show Running Extensions 的实时 CPU 占用看，不能只盯启动时间。
禁用扩展后为什么没变快？这些坑容易漏
禁用操作本身不等于生效。常见疏漏点：
- 只点了 “Disable (Workspace)”，但该扩展在全局仍启用——务必选
Disable (Global)，尤其对ms-vscode.系列 - 禁用后没完全退出 VSCode：
Cmd+Q（macOS）或右上角关闭全部窗口（Windows/Linux），否则扩展主机进程仍在缓存中 - 工作区根目录有
.vscode/settings.json，里面写了"extensions.ignoreRecommendations": false，导致重启后又自动启用被推荐的插件 - 用了 WSL 或 Remote - SSH，但只在本地禁用了扩展——远程端的扩展需单独禁用，
Remote Explorer里切换到对应容器再操作
最稳的验证方式：终端执行 code --disable-extensions --no-sandbox 启动，如果秒开，说明问题确实在扩展；再一个个加回来，比 GUI 点击更可靠。
