VSCode 启动插件耗时可通过 Developer: Startup Performance 查看，重点关注 Activate、Load 和 Activation Events 三列；Activate 超 300ms 且事件为 * 或 onStartup 的扩展最可能拖慢启动；禁用后需重启并对比耗时验证，优先试禁 Remote-SSH、GitLens 等；仍高耗时需检查间接依赖或首次同步；深入分析可用 code --prof-startup 导出火焰图；优化建议包括收敛 activationEvents、延迟重操作、动态导入及关闭非必要功能。
查看 VSCode 启动时各插件加载耗时
VSCode 本身提供了内置的性能分析入口，不需要额外安装工具。按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入并执行 Developer: Startup Performance，就能看到启动阶段每个扩展的加载时间、激活时机和是否为“主要贡献者”。
关键看三列：Activate（激活耗时）、Load（加载耗时）、Activation Events（触发激活的事件）。如果某个扩展的 Activate 超过 300ms 且 Activation Events 是 * 或 onStartup，它大概率是拖慢启动的元凶。
禁用可疑扩展后验证启动速度变化
不要凭印象猜——要对比。先记下当前启动耗时（Developer: Startup Performance 顶部显示的总毫秒数），再逐个禁用高耗时扩展（尤其是那些 Activation Events 为 * 的），每次禁用后重启 VSCode 并重新运行 Developer: Startup Performance。
- 优先试禁用：Remote-SSH、GitLens、Prettier、ESLint、Python（官方）、Docker
- 禁用后仍显示高耗时？说明该扩展可能被其他启用的扩展间接依赖或触发
- 注意：部分扩展（如 Settings Sync）会在首次启动时同步大量数据，首次耗时高属正常，第二次应明显下降
用 --prof-startup 导出详细火焰图
当内置面板看不出瓶颈，或想确认 JS 执行热点时，可手动启动带性能探查的 VSCode：
code --prof-startup --prof-startup-prefix startup-profile
启动完成后，VSCode 会自动生成多个 .cpuprofile 文件（路径见终端输出），用 Chrome 浏览器打开 chrome://tracing，载入这些文件，就能看到函数级调用栈和耗时分布。
重点关注：
-
extensionHost进程中的长任务（>50ms） - 重复出现的
require或activate调用 - 某扩展的
package.json中声明了过多activationEvents，导致提前加载
优化建议：延迟激活 + 条件收敛
如果你自己开发扩展，或能修改配置，以下改动最有效：
- 把
"activationEvents": ["*"]改成具体事件，例如["onLanguage:python", "onCommand:python.runAllTests"] - 避免在
activate()里做重操作：网络请求、大文件读取、初始化复杂语言服务——改用vscode.window.withProgress延后或懒加载 - 检查
package.json中的main入口文件是否过大；拆分逻辑，用import()动态导入非首屏功能 - 某些扩展（如 Auto Rename Tag）提供设置项
auto-rename-tag.enableAutoRenameTag，设为false可跳过初始化
真实场景中，一个扩展从 onStartup 改为 onLanguage:json，常能把启动耗时从 400ms 压到 20ms 以内。但要注意：改得太细会导致功能不可用，得在响应速度和可用性之间找平衡点。
