VSCode启动慢主因是内置扩展强制onStartup激活；典型如ms-vscode.js-debug、vscode-typescript-next、references-view、test-explorer，均以ms-vscode.开头且声明onStartup或*激活事件，禁用可显著提速。
VSCode 启动慢，八成以上是扩展惹的祸；但很多人只盯着第三方扩展，却忽略了几个“默认启用、自带激活事件、从不提醒你它在后台干活”的内置扩展——它们才是真正拖慢冷启动的隐形主力。
哪些内置扩展会强制 onStartup 激活？
VSCode 自带的某些功能模块，虽然不显示在扩展市场里，但本质仍是可启停的扩展，且多数声明了 onStartup 或通配符 * 激活事件。典型包括：
-
ms-vscode.js-debug（JavaScript 调试器）：即使你从不调试 JS，它也会在启动时预热调试服务 -
ms-vscode.vscode-typescript-next（TypeScript 语言支持）：若项目无tsconfig.json，它仍会加载完整 TS 服务 -
ms-vscode.references-view（引用视图）：随编辑器一起初始化，占用内存但极少被主动调用 -
ms-vscode.test-explorer（测试资源管理器）：只要工作区含package.json或常见测试配置，就会自动激活
这些不是“第三方插件”，而是 VSCode 安装包自带的扩展，ID 均以 ms-vscode. 开头，在 Extensions: Show Installed Extensions 中搜索 @builtin 即可列出。
禁用内置扩展的实操路径与风险提示
内置扩展不能卸载，但可以禁用——方式和第三方扩展一致，只是需更谨慎判断依赖关系：
- 打开命令面板（
Cmd+Shift+P），输入并执行Extensions: Show Installed Extensions - 在搜索框中输入
@builtin，过滤出所有内置扩展 - 右键点击目标扩展（如
ms-vscode.js-debug），选择Disable (Global)（不建议仅禁用 Workspace，因它影响所有项目） - 完全退出 VSCode（
Cmd+Q），再重新启动，观察启动耗时变化
⚠️ 注意：ms-vscode.vscode-typescript-next 禁用后，TS/JS 文件将失去语义高亮、跳转、补全等核心能力；若你写前端或 Node，不建议禁用。而 ms-vscode.references-view 和 ms-vscode.test-explorer 在纯配置文件、Markdown 或 Python 项目中基本无用，可放心禁用。
如何验证某个内置扩展是否真在拖慢启动？
别靠猜，用 VSCode 自带的诊断命令直接看数据：
- 启动 VSCode 后立即执行
Developer: Startup Performance - 在弹出的性能报告页中，重点看
Start Delay列 —— 数值超过 300ms 的基本就是嫌疑对象 - 对照列表中的
Extension ID字段，确认是否为ms-vscode.*开头 - 若某扩展
Activation Event显示onStartup且Start Delay高，禁用后重启对比效果最直观
这个命令不依赖第三方工具，结果实时、可信，且能精确到毫秒级延迟来源。
禁用后功能缺失怎么办？
禁用是临时开关，不是删除。所有内置扩展都支持按需手动启用：
- 当你需要调试 JS 时，打开一个
.js文件，VSCode 会提示“调试器未启用”，点击“Enable”即可瞬间激活ms-vscode.js-debug - 同理，打开
test目录或运行Test: Run All Tests命令时，ms-vscode.test-explorer会自动唤醒 - 这种“触发即加载”机制比“一开就占着”省至少 200–500ms 启动时间，且不牺牲功能完整性
真正容易被忽略的点是：很多人禁用了扩展，却没完全退出 VSCode 再启动——缓存仍在，延迟照旧。冷启动才见真效果，热重载不作数。
