VSCode启动速度监测应使用内置命令Developer: Startup Performance，它不增加负担、准确拆解三进程耗时并标出慢扩展；禁用第三方监控插件，因其自加载反而干扰结果。
VSCode 项目启动速度本身不需要插件来监测——它自带诊断能力，装额外插件反而可能干扰结果。
Developer: Startup Performance 是唯一该用的“监测工具”
这是 VSCode 内置命令，不是插件，不增加任何运行时负担，直接反映真实启动耗时分布。它会拆解主进程、渲染进程、扩展主机三块时间，并标出加载最慢的 Extensions 列表。
- 执行方式：按
Cmd+Shift+P（Mac）或Ctrl+Shift+P（Win/Linux），输入并选择Developer: Startup Performance - 重点关注 “Extensions” 总耗时是否 >1.5s；单个扩展若 >300ms，基本就是问题源
- 输出里带红色警告的条目（如
ms-python.python加载 842ms）比任何第三方插件报告都准
code --prof-startup 生成可复现的性能快照
命令行方式比 GUI 更彻底，能捕获从 Electron 进程创建到 UI 渲染完成的全链路耗时，适合对比优化前后差异。
- 终端执行：
code --prof-startup --disable-extensions（先排除插件干扰） - 再执行：
code --prof-startup（含全部插件），对比两个.cpuprofile文件 - 用 Chrome DevTools 打开这些文件，在
Bottom-Up视图里看哪个activate()调用栈最深、耗时最长 - 注意：
--prof-startup生成的文件默认存于系统临时目录，不是项目内，别在.vscode里找
别装“启动监控类”插件，它们全是噪音源
搜索 “startup monitor” 或 “boot time analyzer” 出来的插件，本质都是监听 onStartup 事件后自己打点计时，但它们自己就得先被加载——等于让医生给自己量血压，还开着手术灯。
- 典型反例：
vscode-startup-time、startup-performance-analyzer，安装即激活，反而抬高基线 - 它们无法区分是插件初始化慢，还是文件索引慢，更看不到 Electron 主进程阻塞点
- 部分还会 hook
vscode.window.onDidChangeActiveTextEditor等事件，增加主线程调度压力
真正影响启动速度的，从来不是“测得准不准”，而是你能否快速识别出那个在 activationEvents 里写了 * 或 onStartup 的插件，然后把它从全局禁用，或改用 affinity: 2 延迟加载。所有花哨的可视化图表，都掩盖不了这个事实。
