看状态栏⚡图标（Developer: Toggle Performance Impact），点开见“Typing took Xms — caused by extension 'xxx'”即可定位；90%以上源于扩展onDidChangeTextDocument中未await的同步操作，如fs.readFileSync或无边界正则匹配。
怎么看是哪个扩展在拖慢打字
输入卡顿本质是主线程被同步阻塞，90%以上源于扩展的 onDidChangeTextDocument 回调里做了未 await 的操作。最直接的验证方式是运行 Developer: Toggle Performance Impact —— 它不画图、不录帧，只在状态栏右侧亮起 ⚡ 图标，点开就能看到“Typing took 187ms — caused by extension 'esbenp.prettier-vscode'”这类明确归因。
这个命令只显示“已激活且正在运行”的扩展，所以：
- 如果同一扩展反复出现在延迟列表里，基本可判定它没做异步化或节流
- 常见坑：在 onType 里直接 fs.readFileSync 读配置，或对整行文本跑 /(^|\s)TODO(\s|$)/g 这类无边界锚点的正则
- 注意：Not activated 的插件不会上榜，别白费时间盯它们
怎么确认是不是扩展导致的卡顿
别猜，用 code --disable-extensions 直接验证。关掉所有窗口，在终端执行该命令后打开同一项目，重复卡顿操作（比如连续输入、滚动、保存）：
- 如果卡顿消失 → 100% 是插件问题
- 如果依旧卡顿 → 要转向文件监视（
files.watcherExclude）、语言服务器（Pylance/Jedi 索引）、或系统级配置（如inotify限制）排查
这个命令不加载任何第三方扩展，但保留 VSCode 内置语言支持（如 TypeScript、JSON），所以基础编辑功能仍在，验证干净且可靠。
如何快速定位启动慢的元凶
启动卡顿重点看 Activation Time 字段。按 Ctrl+Shift+P 运行 Developer: Show Running Extensions，重点关注：
-
Activation Time > 500ms的扩展大概率在activate()里做了同步 I/O，比如扫描整个node_modules找依赖、解析巨型 JSON 配置 -
Activation Events是onStartup的扩展一开就抢资源，哪怕你根本不用它对应的功能 - 内存列持续 > 200MB 且 CPU 实时跳动，说明它在后台轮询（比如 GitLens 刷 blame 缓存、ESLint 持续校验全目录）
注意：activationTime 为 -1 表示尚未激活（懒加载），不能直接排除；真正危险的是 isActivated: true 且耗时 > 300ms。
Performance 面板里该盯哪几块
打开 Developer: Toggle Developer Tools → 切到 Performance 标签页 → 点录制 ● → 快速敲几行代码 → 停掉。火焰图里盯三块：
-
Extension Activation长条：某扩展初始化卡住主线程，常因require大模块或同步解析配置 -
Render Blocking红色尖刺：UI 渲染被 JS 阻塞，通常对应扩展的同步 DOM 操作或 Webview 通信 -
extensionHost下的长任务块：右键 → “Zoom to Selected”，看堆栈顶层是不是你怀疑的扩展名，再往下找是不是onDidChangeTextDocument→parseConfigSync→fs.read
真实用户感知延迟 >16ms 就会掉帧，比 CPU 百分比更准。很多卡顿不是“等一下就好”，而是主线程被锁死超过 200ms 的明确信号。
