VSCode无内置性能分析器，但可用四个原生命令定位卡顿：1. Open Process Explorer查实时资源占用；2. Toggle Performance Impact看用户感知延迟；3. Start/Stop Extension Host Profile生成火焰图分析；4. --disable-extensions验证扩展影响。
VSCode 没有“性能分析器”这个内置功能，但它的原生命令足以定位 90% 的卡顿和资源占用问题——关键不是装插件，而是用对这四个命令。
Developer: Open Process Explorer 看实时资源占用
这是最直接的入口，相当于 VSCode 的任务管理器。它不显示“平均值”，只展示此刻每个进程的真实 CPU % 和内存 MB 数。
- 重点关注
Extension Host下的子项：比如esbenp.prettier-vscode或ms-python.python，若某扩展 CPU 长期 >10% 或内存持续上涨，基本就是它在后台轮询或解析大文件 - 右键可临时终止该进程（缓解卡顿），但要真正释放内存，必须重启 VSCode —— 仅重载窗口无效
- 别只看单帧数值：连续盯 15 秒，有些插件只在保存/格式化瞬间爆发（比如 ESLint 全目录 on-save 检查）
Developer: Toggle Performance Impact 查用户感知延迟
这个命令不画图、不采样，只在状态栏亮一个 ⚡ 图标，点开就能看到“哪次操作慢、谁拖的后腿”。它反映的是真实打字/补全/保存时的阻塞时间，比 CPU 百分比更贴近“卡不卡”。
- 典型提示如：
Typing took 142ms — caused by extension 'aaron-bond.better-comments'，说明该插件在onType回调里做了同步 I/O（比如读取配置文件没加await） - 配合
Developer: Show Running Extensions查它的activationTime：若 >500ms，大概率初始化阶段有未优化正则或同步fs.readFileSync - 它只记录最近一次触发的操作，所以要复现卡顿动作（比如快速输入 5 行再回删）才能捕获到信号
Developer: Start/Stop Extension Host Profile 生成火焰图
当你确认某个扩展有问题，但看不出具体哪段代码拖慢时，就得靠这个导出 .cpuprofile 文件，再用 Chrome DevTools 打开分析。
- 操作必须闭环：执行
Start→ 复现卡顿动作（如打开一个 .ts 文件并触发补全）→ 立即执行Stop，否则火焰图混杂噪音 - 在 Chrome DevTools 的火焰图中，点击顶部函数条，重点看
Self Time：如果某插件的provideCompletionItems或activate方法占了 80% 自身耗时，就不用往下翻了 - 导出的文件是 JSON 格式，不能双击打开；必须手动拖进
chrome://devtools的 Performance 面板里加载
code --disable-extensions 是唯一硬性验证手段
这不是“试试看”，而是隔离变量的必要步骤。只要禁用所有扩展后卡顿消失，就能 100% 锁定是扩展导致——哪怕你刚禁用了 20 个，也比猜哪个 settings.json 配置写错了高效得多。
- 终端运行：
code --disable-extensions --no-sandbox（macOS/Linux）或 Windows PowerShell 中同命令 - 注意：它跳过所有用户扩展，但保留 VSCode 内置语言服务（如 TypeScript、JSON 支持），所以如果此时仍卡，问题可能出在工作区本身（比如巨型
node_modules或未 exclude 的日志目录） - 禁用后若恢复流畅，再逐个启用扩展，观察
Developer: Show Running Extensions中 CPU 列是否突然跳动——这才是定位真凶的最快路径
真正容易被忽略的点是：VSCode 的“卡”，往往不是某一行代码慢，而是某个扩展在主线程里做同步操作（比如读取 50MB 的 JSON 配置），导致整个 UI 停摆。这时候看 CPU 百分比可能只有 5%，但用户感知延迟高达 300ms。所以别只盯着 Process Explorer 的数字，一定要结合 Toggle Performance Impact 和火焰图里的 Self Time。
