vscode本身不提供js运行时性能火焰图，必须依赖chrome devtools等外部工具链；其内核无内置采样式profiler，调试需配置--inspect-brk并点击状态栏链接打开专用devtools进行performance录制分析。

VSCode 本身不提供 JS 运行时性能火焰图

VSCode 编辑器内核不内置 CPU/内存采样式 profiler（比如 Chrome DevTools 那种火焰图），它只负责编辑、调试和语言服务。真正分析 JS 代码执行瓶颈，必须依赖外部工具链或调试协议。直接在 VSCode 里点几下就想看到“哪个函数耗时最长”，这事办不到——Developer: Open Process Explorer 看的是 VSCode 自身进程，不是你写的 JS 脚本。

用 Node.js 调试器 + Chrome DevTools 做真实性能分析

这是目前最可靠、零侵入、可复现的方式。关键在于启动参数和连接路径，稍有偏差就看不到火焰图。

• 确保 launch.json 中启用 V8 Inspector："runtimeArgs": ["--inspect-brk"]（加 -brk 可停在第一行，方便设置采样起点）
• 启动调试后，状态栏出现 Open dedicated DevTools for Node.js 链接，**必须点它**，不能手动打开 chrome://inspect 并手动选中——后者常因端口或上下文隔离失败
• 在 Chrome DevTools 的 Performance 标签页点击录制，执行目标操作（如调用某个计算密集型函数），停止后查看 Bottom-Up 视图，重点关注 Self Time 高的函数
• 注意：如果用 nodemon，需显式传参 --inspect，且避免端口冲突；node --inspect 是唯一被 VSCode 调试器原生支持的模式

哪些插件能辅助定位 JS 性能问题（但不替代 profiler）

它们不生成火焰图，但能提前暴露隐患，比如过大 bundle、未优化的循环、可疑的同步阻塞调用。

Miller CSV TSV JSON 数据处理器

Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。

下载

• ESLint 配合 eslint-plugin-performance：检测 console.time 漏用、Array.prototype.map 嵌套过深、setTimeout 无清理等易被忽略的反模式
• Import Cost：在 import 行旁实时显示模块体积，快速识别“引入一个 UI 库却只用了一个 Button”的浪费行为
• Project Statistics：显示当前工作区最大单文件大小，若发现 >2MB 的 .json 或日志文件，它大概率是语法高亮和搜索卡顿的根源，而非你的 JS 逻辑
• Code Metrics：对 JS/TS 函数做圈复杂度统计，复杂度 >15 的函数值得优先放入 Performance 面板重点观察

别让插件自己变成性能瓶颈

很多号称“JS 优化助手”的插件，实际在后台持续运行 AST 解析或正则匹配，反而拖慢编辑器响应。典型陷阱包括：

• 同时启用 Prettier、ESLint 和 Beautify 的保存时格式化，三者争抢 onSave 事件，导致保存延迟明显，误判为“JS 执行慢”
• Auto Import 类插件在大型 TS 项目中频繁触发类型检查，占用 Extension Host CPU，Developer: Show Running Extensions 里能看到它启动耗时 >300ms
• 主题类插件加载大量 SVG 图标（尤其带动画的），会显著增加 Renderer 进程内存，滚动大文件时 UI 卡顿，容易被当成 JS 渲染性能差

真正卡顿往往不在你的业务代码里，而在编辑器如何加载、解析、渲染它——先确认是“代码跑得慢”，还是“VSCode 看它看得太累”。