直接运行developer: startup performance可定位80%启动慢问题，重点关注extension activation占比超40%、configuration load耗时高、service initialization拖尾三类瓶颈，它比--prof-startup更直观实用。

VSCode 启动慢，直接用内置 Developer: Startup Performance 就能定位 80% 的问题根源，不用装插件、不依赖外部工具。

怎么看启动各阶段耗时

按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入 Developer: Startup Performance 并回车。页面会列出从进程创建到 UI 渲染的完整时间线，关键看三块：

• Extension Activation 占比超过 40%，说明扩展在抢资源
• Configuration Load 耗时高，可能 settings.json 过大或含复杂校验逻辑
• Service Initialization 拖尾明显，常是语言服务器（如 Pylance、cpptools）预加载导致

为什么 Developer: Startup Performance 比 --prof-startup 更实用

--prof-startup 生成的是原始 V8 CPU Profile（cpu-*.json），必须手动拖进 chrome://tracing 解读，且只反映主线程 JS 执行，漏掉扩展宿主进程（Extension Host）的真实开销。而 Developer: Startup Performance 是 VSCode 自己打点汇总的结果，直接暴露“哪个扩展激活花了 1247ms”“哪段配置解析卡了 380ms”，更贴近真实瓶颈。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• 它不依赖 Chrome，打开即见数据
• 显示每个扩展的激活耗时，精确到毫秒
• 标注了是否因 activationEvents: "*" 导致无差别加载

查出问题后怎么快速验证

看到某个扩展（比如 esbenp.prettier-vscode）激活耗时异常高，别急着卸载，先做两件事：

• 右键该扩展 → Disable (Workspace)，重启 VSCode，再跑一次 Developer: Startup Performance 看耗时是否回落
• 检查它是否支持 extensions.experimental.affinity：在 settings.json 中加 "esbenp.prettier-vscode": 2，这会让它延迟到你真正打开 .js 或 .ts 文件时才激活
• 确认 files.watcherExclude 是否生效——如果漏配 "**/node_modules/**": true，文件监视器 fallback 到轮询，会把所有扩展的初始化时间拉长 2–3 倍

真正容易被忽略的是：启动分析结果里显示“快”的模块，未必真轻量；它可能只是把重活扔给了后台 Extension Host 进程，而 Developer: Startup Performance 不统计那部分。所以只要看到启动慢，先禁用一半扩展再测，比盯着火焰图猜更有效。