VSCode无内置火焰图渲染能力，所有“火焰图插件”仅调用第三方库（如speedscope）展示由Node.js（--prof/--inspect）或Chrome DevTools生成的数据；真正采集性能数据的是运行时进程本身，而非VSCode。
VSCode里根本没内置火焰图插件
别被“火焰图”三个字带偏——VSCode 自身不提供火焰图渲染能力，所有所谓“火焰图插件”只是把 node --prof 日志或 Chrome DevTools 导出的 JSON 丢给第三方可视化库（比如 speedscope）打开。真正生成数据的，永远是 Node.js 进程本身。
你装了 10 个“火焰图插件”，如果没让 Node 启动时带 --prof 或 --inspect，就什么图都看不到。这是最常被忽略的前提。
-
--prof用于 CPU 火焰图：启动时加参数，运行后用node --prof-process解析生成isolate-*.log -
--inspect用于内存快照 + Chrome Performance 面板录制：必须手动连接chrome://inspect才能拿到火焰图 - VSCode 的
JavaScript Debugger（预装）只负责建立调试连接，不生成也不渲染火焰图
死循环定位靠 --inspect + Performance 录制
死循环不会立刻崩溃，但会让 Event Loop 卡死、CPU 持续 100%、setTimeout 和 Promise.then 大量延迟。这时候不能只看堆内存，得抓运行时行为。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 在
launch.json中配置"runtimeArgs": ["--inspect-brk"]，确保一启动就暂停，避免漏掉早期循环入口 - 启动后立即打开
chrome://inspect→ Configure → 加localhost:9229→ 刷新 → 点inspect - 切到
Performance标签页，点录制按钮（●），等几秒后停止，重点关注：JS Heap是否平稳、Event Loop Delay是否飙升、Top Down里哪个函数调用栈深度异常高 - 如果录制中完全没响应，大概率是同步死循环（比如
while(true)或递归没出口），此时直接 Ctrl+C 终止进程，改代码再试
内存泄漏必须用 Chrome Memory 面板对比快照
VSCode 调试器里的“内存”视图只能看当前堆大小数字，没法查谁占着不放。真要定位泄漏，必须用 Chrome DevTools 的 Memory 面板做堆快照对比。
- 不要用
launch.json直接launch方式启动——那样无法捕获进程初始化阶段的闭包引用和全局缓存误存 - 改用终端手动启动：
node --inspect=9229 --max-old-space-size=512 app.js（限制堆大小，加速泄漏暴露） - 在 Chrome
Memory面板里，至少拍 3 次快照：初始态 → 触发可疑操作（如请求接口）→ 再触发一次 → 等 GC 发生后 - 右键快照 →
Compare to previous snapshot，按Retained Size倒序，重点展开Closure、Array、Buffer下的Retainers，找cache、handlers、pendingRequests这类变量名
容易被忽略的两个硬性条件
哪怕配置全对，漏掉下面任一条件，火焰图或快照都会失效或失真。
-
--inspect端口必须与launch.json中"port"字段一致，且不能被其他进程占用（比如另一个 Node 实例或 Webpack Dev Server） - Chrome 浏览器必须是最新稳定版；旧版 DevTools 对 Node.js v20+ 的某些堆结构解析错误，导致 Detached 对象识别失败
火焰图不是“配完插件就自动出来”的东西，它本质是一次受控的运行时采样过程。从 --inspect 启动，到 Chrome 连接，再到录制/快照/对比，每一步都得手动确认状态，跳过任何一环，看到的就只是空白或误导数据。
