VS Code 启动慢应优先用 Developer: Toggle Developer Tools 查看 Performance 标签页及 code --status 输出，重点关注 Startup 耗时、activationTime > 500ms 的扩展及 extensionHost 总耗时。
VS Code 启动慢？先看 Developer: Toggle Developer Tools 里的 console 和 Performance 标签页
VS Code 卡顿不一定来自扩展，也可能是渲染进程阻塞或主进程加载异常。打开开发者工具（快捷键 Ctrl+Shift+P → 输入 Developer: Toggle Developer Tools），切到 Performance 标签页点录制，再重启窗口，能直接看到耗时最长的模块——比如 workbench.desktop.main.js 初始化阶段是否被某个扩展的 activate() 拖住。
- 常见错误现象：
Extension Host进程 CPU 持续 >80%，但扩展列表里没明显“大块头” - 真实场景：某些扩展在
activate()里同步读取大文件、调用未加timeout的网络请求，或反复触发vscode.workspace.onDidChangeConfiguration - 关键参数差异：VS Code 1.85+ 默认启用
"extensions.experimental.affinity": { "ext-id": 1 }控制扩展运行位置，设为2可强制进独立进程，便于隔离观察
code --status 输出里哪些字段真正反映扩展拖慢启动
命令行运行 code --status 是最轻量的诊断方式，但很多人只扫一眼就跳过。重点盯紧三列：Startup（从进程启动到界面可交互耗时）、Extensions 下各扩展的 activationTime，以及末尾的 extensionHost 启动总耗时。
- 容易踩的坑：
activationTime为-1表示该扩展尚未激活（懒加载），不能直接排除；真正危险的是activationTime > 300且isActivated: true - 性能影响：单个扩展
activationTime > 500ms就会明显拖慢冷启动；若多个扩展合计超1200ms，用户大概率感知卡顿 - 兼容性注意：
--status在 macOS 上需用code-insiders --status（稳定版有时不输出完整扩展耗时）
用 Process Explorer 定位具体哪个扩展进程吃 CPU
Windows 用户直接用系统自带的 Process Explorer（微软官方工具），macOS / Linux 用户用 htop -T 或 ps aux --forest | grep vscode，找带 --type=extensionHost 或 --extensionDevelopmentPath 的子进程。
- 常见错误现象：任务管理器里看到多个
Code Helper (Renderer)，但无法对应到扩展名——此时右键进程 →Properties→Image Path，路径末尾通常含扩展 ID（如ms-python.python） - 使用场景：某扩展在后台偷偷轮询 API（比如 GitLens 的提交图自动刷新），
console里没报错，但进程常驻高 CPU - 实操建议：临时禁用可疑扩展后，用
kill -SIGUSR2（Linux/macOS）触发 V8 堆快照，再用 Chrome DevTools 打开分析内存泄漏点
8 个扩展里真正值得留下的只有 3 个：优先级排序逻辑
所谓“8 个性能分析扩展”，实际多数功能重叠或已过时。真正能精准归因的只有：Performance Inspector（可视化主线程帧率）、Extension Bisect（二分法自动禁用定位元凶）、Running Extensions（实时显示每个扩展的 CPU/内存占用）。
-
Project Statistics和Code Metrics看的是代码复杂度，和运行卡顿无关 -
VS Code Startup Profiler已被 VS Code 1.79+ 内置的Developer: Startup Performance命令替代 - 最容易被忽略的点：
Extension Bisect必须配合--disable-extensions启动一次再运行，否则它默认从“已启用状态”开始二分，可能漏掉首次激活即崩溃的扩展
