developer: startup performance报告是定位vscode启动卡顿的权威依据，需重点关注extensions总耗时（＞1.5s危险）、单个扩展activate plugin time（＞300ms标红必查）及renderer渲染进程初始化（＞800ms提示ui层扩展或主题拖慢）。
Developer: Startup Performance 报告怎么看
它不是“看看就行”的工具，而是唯一能告诉你“哪一段卡了多久”的权威依据。打开后重点盯三个位置：Extensions 总耗时（超过 1.5s 就危险）、Activate Plugin Time 单个扩展启动时间（>300ms 的标红项必须查）、Renderer 渲染进程初始化是否被阻塞（若 >800ms，大概率是 UI 层扩展或主题在拖慢）。
常见错误现象：报告里 Extensions 耗时占总启动时间 60% 以上；某个扩展的 Activate Plugin Time 显示 “N/A” 或 “0ms”，但实际加载很慢——这说明它没正确声明 activationEvents，属于“无脑启动型”扩展，必须干预。
code --disable-extensions 启动后仍慢，问题在哪
说明瓶颈不在扩展，而是在 VSCode 自身或系统层。这时要立刻排除两个方向：
- 工作区过大：用
code --disable-extensions /tmp/empty启动一个空目录，如果秒开，问题就在你当前项目。检查.vscode/settings.json是否启用了files.watcherExclude，漏掉**/build/**或**/.next/**这类高频变更目录会触发海量 inotify 监听 - 主进程阻塞：Linux/macOS 下执行
code --disable-extensions --log-level=trace --prof-startup，导出 JSON 后看main进程中require阶段是否卡在某个模块加载上（比如node_modules/electron或vs/platform/.../service），这往往指向 VSCode 二进制损坏或磁盘 I/O 瓶颈
extensions.experimental.affinity 设为 2 为什么没效果
因为该配置只对明确支持延迟激活的扩展生效，且必须写在用户级 settings.json（不是工作区级），否则会被覆盖。更关键的是：它不改变扩展是否“安装”，只改变“何时加载”。如果你发现设了 "ms-python.python": 2 后 Python 扩展还是启动就加载，说明它根本没声明 onLanguage:python 这类 activationEvents，或者你正打开一个 .py 文件——那它当然得立刻激活。
实操建议：
- 确认扩展是否真支持：查其
package.json中是否有"activationEvents"字段（市场页点“Contributions”可看） - 不要给所有扩展都设 affinity：像
vscode-icons、material-icon-theme这类纯 UI 扩展设了也无效，它们本就不需要延迟 - 数字含义：1 = 主进程加载，2 = 渲染进程加载（推荐），0 = 强制禁用（慎用）
Startup Profiler 视图打不开或数据为空
这是 VSCode 2026 新版的已知兼容问题，尤其发生在 macOS Sequoia + Apple Silicon 组合下。根本原因是 V8 采样器与 Metal 渲染后端存在初始化竞争，导致 trace 数据未完整写入。
绕过方法：
- 改用命令行生成原始 trace：
code --prof-startup --disable-extensions --log-level=off，等窗口完全出现后立即Cmd+Shift+P→Developer: Stop Tracing，再手动打开生成的trace.json - 临时关闭 GPU 加速：
code --disable-gpu --disable-extensions，虽然界面略卡，但能确保 trace 数据完整 - 别依赖 UI 视图，直接看 JSON 里的
traceEvents数组，过滤name: "activatePlugin"的事件，按dur倒序就能揪出真凶
真正容易被忽略的点是：VSCode 启动慢很少由单个原因导致，往往是 extensionHost 加载慢 + files.watcherExclude 漏配 + typescript.preferences.includePackageJsonAutoImports 设为 auto 三者叠加。诊断时别只盯着一个环节。
