VSCode性能分析需分三步：先用Developer: Show Running Extensions查激活耗时超500ms的插件；再用Developer: Toggle Developer Tools的Performance面板追踪Extension Host长任务；最后用code --status看启动时间占比，重点排查onStartup触发的插件组合影响。
打开插件性能分析面板用 Developer: Show Running Extensions
VSCode 自带的实时扩展监控面板能直接告诉你哪些插件正在消耗 CPU、内存，以及是否在启动时拖慢了编辑器。这不是第三方工具，不需要安装额外插件，按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入并执行 Developer: Show Running Extensions 即可打开。
这个面板会列出所有已启用插件，并显示三项关键指标：Activation Time（激活耗时）、Load Time（加载耗时）、Runtime Impact（运行时影响）。其中 Activation Time 超过 500ms 的插件，基本就是你开机后等编辑器“卡一下”的元凶。
- 注意区分
Activation Time和Load Time：前者是插件响应触发条件（比如打开 .js 文件）所花的时间，后者只是加载代码进内存的时间；真正拖慢操作体验的通常是前者 - 如果某插件显示
Not activated，说明它还没被触发，当前不构成性能负担 - 面板默认只显示“已启用”插件，禁用的不会出现——所以想对比影响，得先启用再看
用 Developer: Toggle Developer Tools 查看主线程阻塞
有些插件虽然激活快，但会在后台频繁执行同步操作，把 VSCode 的 UI 主线程堵住，导致打字延迟、滚动卡顿。这时候要开开发者工具看 Performance 面板追踪。
执行 Developer: Toggle Developer Tools 打开 DevTools，切换到 Performance 标签页，点录制（●），做几个典型操作（比如快速开关文件、输入几行代码），停掉录制后查看火焰图。重点关注标为 Extension Host 的长任务块。
- 常见问题模式：某个插件的
onDidChangeTextDocument回调里做了同步正则替换或大数组遍历，会导致每打一个字都卡一次 - 火焰图里看到大量
vscode-fileWatcher或vscode-scm相关长任务，往往不是 Git 插件本身的问题，而是它监听的文件夹里有海量小文件（比如node_modules或构建产物） - 不要只盯着“总耗时”，更要看单次调用是否超过 16ms（即掉帧阈值）
禁用插件后仍残留性能影响？检查 extensions/exploration 和 extensionKind
有时候你禁用了某个插件，但它的进程还在跑，或者它改写了其他插件的行为逻辑（比如 Prettier + ESLint 插件共存时互相触发格式化），导致你以为“关了就没事”，其实没真正退出。
执行 Developer: Show Running Extensions 后，点击插件名旁的齿轮图标，能看到该插件实际运行在哪种进程里：UI（渲染进程）、Workspace（工作区进程）还是 Remote（远程连接时）。部分插件（如 GitLens）即使被禁用，在打开 Git 仓库时仍可能以 workspace 模式自动激活。
- 某些插件在
package.json中声明了"extensionKind": ["ui", "workspace"]，意味着它会被强制加载到多个进程，禁用后也可能留有痕迹 - 路径
~/.vscode/extensions/下的exploration子目录，是 VSCode 实验性插件缓存区，里面残留的旧版插件有时会干扰性能统计，可手动清空 - 远程开发（SSH/Containers）场景下，插件实际运行在远端机器上，本地
Developer Tools看不到其主线程，得登录远端查ps aux | grep extensionHost
用 code --status 命令行快速获取启动性能摘要
不想每次开 GUI 面板？终端一行命令就能拿到冷启动数据。在任意目录下运行：
code --status
输出里最关键的三行是：Startup time:（总启动毫秒数）、Extensions startup time:（插件总激活耗时）、Extension activation times: 下列出每个插件的具体激活时间。这个结果比 GUI 面板更全，连被跳过的插件（not activated）也会显示出来。
- 如果
Extensions startup time占了总启动时间 70% 以上，说明插件确实是瓶颈，而不是 VSCode 本身或系统环境问题 -
Extension activation times列表里带[activation event: *]的，表示它是“懒加载”触发的，而带[activation event: onStartup]的，是开机必载，优先排查这类 - macOS 上若看到
Startup time异常高（>3s），先检查是否启用了Apple Events权限限制（系统设置 → 隐私与安全性 → 自动化），VSCode 需要该权限才能快速唤起窗口
onStartup 时抢着初始化，就会叠加成秒级延迟。别只盯着单个数字，重点看触发时机和资源争用。 
