登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  软件教程

VS Code 怎样查看扩展激活耗时

来源:17golang原创

时间:2026-11-07 22:02:58 389浏览 收藏

VS Code 自带的 Developer: Startup Performance 命令可以查看启动阶段的性能报告,其中包含扩展激活统计。打开报告后,重点看扩展名、激活原因、代码加载耗时和 Finish Activate 等字段,就能判断某个扩展是在加载代码时变慢,还是在执行 activate 阶段占用时间。

最短路径是:打开 Command Palette,运行 Developer: Startup Performance,再在 Extension Activation Stats 表格中按扩展名定位耗时。这个报告用于诊断当前启动过程,不等同于扩展在所有机器上的固定耗时。

官方地址:https://code.visualstudio.com/updates/v1_144

下面按“入口、报告、字段、判断”四步说明。整篇只讨论如何查看和解释扩展激活耗时,不把一次报告中的示例数字当成你的实际测量结果。

先明确要看的不是窗口总耗时

VS Code 启动慢时,窗口总耗时只能说明“整体变慢了”,不能直接告诉你是哪一个扩展拖慢了启动。Startup Performance 编辑器会把启动阶段的重要性能标记和扩展激活统计放在同一份报告里,适合先做高层定位。

报告字段它回答的问题阅读重点
Extension哪个扩展参与了这次激活先定位具体扩展标识
Activation reason它为什么在此时被激活区分启动、工作区或语言触发
Code loading time加载扩展代码花了多久关注打包体积、模块加载和文件读取
Finish Activate扩展完成 activate 调用花了多久优先用来找执行逻辑偏慢的扩展

因此,标题中的“激活耗时”不是只抄一个数字,而是先看扩展身份,再结合触发原因和两个耗时阶段判断问题落点。

第 1 步:打开 Command Palette

在 VS Code 窗口中选择 View > Command Palette。也可以直接按 F1,macOS 使用 ⌘⇧P,Windows/Linux 使用 Ctrl+Shift+P。成功后,屏幕中央会出现一个可输入命令的搜索框。

如果你经常用键盘操作,直接按快捷键更快;如果快捷键被系统或输入法占用,从菜单进入即可。此时不要在 Extensions 侧栏里搜索扩展名,因为那个入口用于安装和管理扩展,不会打开启动性能报告。

原创 VS Code 类编辑器说明图,Command Palette 中高亮 Developer Startup Performance 命令
图1:Command Palette 入口说明图,展示需要选择的性能命令;这是原创静态说明图,不是实际软件截图。

第 2 步:运行 Developer: Startup Performance

在 Command Palette 输入 Developer: Startup Performance,选择同名命令并回车。VS Code 会打开一个 Startup Performance 编辑器,报告通常以编辑器标签页形式出现,而不是在终端打印一段日志。

官方命令行入口也提供了同一方向的快捷方式。如果当前环境已经能直接调用 code 命令,可以执行:

# 直接进入 VS Code 的启动性能报告,便于重复采集诊断信息
code --performance

命令行参数只负责打开性能入口,不会替你判断哪个扩展有问题。报告打开后仍要回到扩展激活统计表中阅读。

第 3 步:在报告里找 Extension Activation Stats

打开报告后,先找到 Extension Activation Stats 区域。这里可以按扩展标识逐行查看激活相关信息;不要把报告里的静态示意数字直接当成你的机器结果,真正有用的是你这次启动对应的扩展行和字段关系。

定位某个扩展时,建议按下面的顺序阅读:

  1. 先看 Extension:确认行对应的确实是目标扩展,而不是同一厂商的另一个扩展或扩展包成员。
  2. 再看 Activation reason:确认它是因为启动、工作区条件、语言文件还是其他事件被激活。
  3. 最后看 Code loading time 和 Finish Activate:前者更像加载代码的成本,后者更接近扩展完成激活逻辑所用的时间。
原创软件界面说明图,Startup Performance 报告列出扩展激活原因和耗时字段
图2:扩展激活统计表的阅读方式说明图,突出扩展名、激活原因和耗时字段;这是原创静态说明图,不是运行证据。

第 4 步:用两个耗时字段判断问题位置

如果 Code loading time 明显偏高,而 Finish Activate 相对正常,优先检查扩展打包后的代码量、启动时同步加载的模块以及文件读取路径。如果代码加载不高,但 Finish Activate 偏高,重点转向扩展的初始化逻辑,例如启动时扫描工作区、读取配置、建立连接或等待外部资源。

还要把 Activation reason 放在一起看。一个扩展可能并不是每次打开空窗口都会激活,只有打开特定语言文件或满足工作区条件时才触发。因此一次报告里“没看到它”不代表扩展不存在,“看到它耗时很高”也只说明这次触发路径需要进一步复现。

现象先查什么不要直接下的结论
Code loading time 高模块加载、打包体积、启动时同步读取不要马上认定业务逻辑慢
Finish Activate 高activate 内部初始化和外部依赖不要只看扩展安装大小
多个扩展同时变高扩展主机是否被某个慢激活阻塞不要按行简单相加得出用户体感
不同工作区结果不同Activation reason 和工作区条件不要把一次结果当成全局基准

常见问题

找不到 Developer: Startup Performance 怎么办? 先确认输入的是完整命令名,并从 Command Palette 的命令结果中选择带有 Developer: 前缀的项。也可以用 code --performance 作为替代入口。

Finish Activate 是不是扩展的全部耗时? 不是。它用于观察扩展完成激活调用的阶段,代码加载和其他启动阶段仍要结合报告中的其他信息判断。

能不能只看 Extensions 侧栏判断耗时? 不建议。侧栏适合安装、禁用和管理扩展,启动性能报告才提供激活原因与耗时字段。

报告里的耗时可以直接和别人的机器比较吗? 不应直接比较。硬件、操作系统、工作区规模、远程环境和激活条件都会影响结果,最好在相同工作区和相近启动路径下重复观察。

回到标题问题,操作路径就是:View > Command Palette → Developer: Startup Performance → Extension Activation Stats。先用扩展名确认对象,再用激活原因解释为什么触发,最后对照 Code loading time 与 Finish Activate 判断慢在加载还是初始化。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>