VSCode性能分析需组合原生命令与外部工具：用Developer: Open Process Explorer查扩展内存/CPU占用（Memory>300MB或CPU连续10秒>25%需关注），Developer: Toggle Performance Impact识别真实卡顿（如Typing took 142ms），Developer: Start/Stop Extension Host Profile导出.cpuprofile并用Chrome DevTools分析火焰图，Node.js/Python等项目则需配合--inspect、py-spy等外部profiler。
VSCode 没有内置的“性能分析器”，所谓“使用心得”本质是组合原生命令 + 外部工具 + 合理采样时机的一套工作流，不是点几下就能出火焰图。
Developer: Open Process Explorer 看什么
这是唯一能告诉你“谁在吃资源”的原生命令，不是看系统任务管理器里模糊的 Code Helper 进程。
-
Memory列单位是 MB，关掉所有文件后还 >300MB 的扩展大概率有问题 -
CPU看连续 10 秒是否稳定 >25%，单次峰值没意义——有些插件只在保存时爆发 - 重点盯
Extension Host下的子项，比如ms-python.python或esbenp.prettier-vscode，右键可禁用但必须执行Developer: Restart Extension Host才释放内存
Developer: Toggle Performance Impact 判定真实卡顿
CPU 占用低 ≠ 不卡，真正拖慢编辑体验的往往是同步阻塞操作。
- 启用后状态栏出现 ⚡ 图标，点开能看到类似
Typing took 142ms — caused by extension 'aaron-bond.better-comments' - 它反映的是主线程被锁住的时间，比 CPU 百分比更贴近“打字卡顿”这种感知
- 常见原因：插件在
onType回调里没加await就读大文件、跑复杂正则、或调用未优化的本地命令
Developer: Start/Stop Extension Host Profile 导出火焰图
确认某个扩展有问题后，得靠这个定位具体哪段 JS 代码拖慢，但导出的 .cpuprofile 文件不能直接在 VSCode 里打开。
- Start → 复现卡顿操作（比如打开一个 .ts 文件并触发补全）→ 立即 Stop
- 生成的文件要用 Chrome DevTools 打开：
chrome://devtools→ Performance → 右上角 ⋯ →Load profile - 关键看顶部长条的
Self Time，展开调用栈找activate()或provideCompletionItems()这类插件入口方法 - 注意：火焰图只记录 JS 执行，不包含 Node.js 底层调用；若怀疑是原生模块问题，得换
py-spy或--inspect配合 DevTools 分析目标进程
Node.js / Python / 前端项目怎么连外部 profiler
VSCode 本身不分析你的代码，它只是调试协议的中转站，真正干活的是 V8、py-spy 或 Chrome DevTools。
- Node.js：launch.json 里加
"runtimeArgs": ["--inspect"]，启动后点状态栏Open dedicated DevTools for Node.js，进 Performance 面板录制 - Python：终端查 pid（
ps aux | grep python），再运行py-spy record -p <code>PID-o profile.svg --duration 10；Windows 要管理员权限，conda 环境要确保 py-spy 安装在同一环境 - 前端页面：装
Debugger for Chrome或Microsoft Edge Tools，launch.json 设"type": "pwa-chrome"，关键参数"trace": true可生成底层.trace文件供chrome://tracing查看
真正卡住人的往往不是工具怎么用，而是采样时机没对上——比如在热更新（HMR）开启时录 CPU Profile，会把模块重载逻辑一起算进去；或者在 Extension Host Profile 里等太久才 Stop，导致火焰图太宽、噪音太多。动手前先想清楚：我要测的是启动？保存？还是输入响应？目标场景定了，工具链才不会跑偏。
