火焰图是分析javascript性能最直观手段，通过顶层宽条定位热点函数，顺调用链下钻识别深层开销，结合差分图锁定变化点，并需关联其他指标避免仅关注cpu。
火焰图是分析 JavaScript 运行时性能最直观有效的手段之一，尤其适合处理深度嵌套、异步交织、多层抽象的复杂调用栈。它不依赖代码埋点或重构，直接反映 CPU 时间真实分布，帮你跳过猜测，直击瓶颈。
看顶层“宽条”：定位第一级热点函数
火焰图顶部（Y 轴最上方）的矩形代表当前正在执行的函数，其宽度反映该函数被采样到的频率——也就是实际占用 CPU 时间的比例。宽度越宽，说明它越可能是性能瓶颈的源头。
- 若 顶层出现一个明显宽于周围的大块（平顶），比如
parseJSON、newObject或某个自定义渲染函数，优先检查它内部逻辑是否含同步大计算、低效遍历或未节流的递归调用； - 若多个宽条并列（如
get_field、call_method、assign都很宽），说明瓶颈可能在通用运行时操作上，需结合上下文判断是否由高频对象访问、动态属性读写或原型链过长引发； - 注意区分 用户代码 vs 引擎/框架/库代码：Chrome DevTools 火焰图默认高亮用户脚本（通常标为
your-script.js），可右键过滤“Hide system libraries”聚焦业务逻辑。
顺调用链下钻：识别深层隐藏开销
从顶部向下看，每一层都是它的调用者。火焰图不是时间线，而是“所有采样堆叠后按字母排序”的聚合视图，但调用关系依然清晰可溯。
- 点击一个宽条，火焰图会水平放大，仅显示该函数及其全部子调用路径，方便你逐层展开，例如：从
renderList→map→createItem→deepClone，最终发现耗时集中在最后一环； - 留意“细长尖刺”：某函数本身不宽，但它下方突然展开一大片窄条，说明它触发了大量短生命周期但高频率的子调用（如频繁创建临时对象、反复调用
toString()或正则test()），这类问题容易被忽略； - 关注异步边界：在 Promise 链或
async/await场景中，火焰图常显示promiseReactionJob、microtask等调度节点。若这些节点本身变宽，往往意味着微任务队列积压，根源可能是同步逻辑过重或未正确使用queueMicrotask分片。
对比不同场景：用差异火焰图锁定变化点
单张火焰图只能告诉你“现在哪里慢”，而两张图的差异才能回答“为什么变慢了”。比如升级某依赖、切换数据量级、或启用新功能后性能下降。
- 使用 Chrome 的 Performance 面板录制两次：一次基准（小数据）、一次问题场景（大数据），导出 JSON 后用 FlameScope 或 FlameGraph 工具链 生成差分火焰图（Differential Flame Graph）；
- 差分图中，红色区域表示新增/加剧的耗时，蓝色表示减少。若某函数在新版中突然变红加宽，即使它原来也存在，也值得重点审查；
- 特别注意跨帧行为：滚动、动画、输入响应等交互场景中，火焰图可能显示
requestAnimationFrame内部持续高负载。此时可配合“Frames”面板查看每帧耗时，再回到火焰图定位具体哪一帧的 JS 执行拖垮了帧率。
关联其他指标：避免只看 CPU 忽略阻塞
标准火焰图（On-CPU）只展示 CPU 正在执行的时间，但 JavaScript 性能卡顿未必都来自 CPU 计算——也可能因 I/O 等待、锁竞争、GC 暂停或主线程被同步操作长期霸占。
- 在 Chrome Performance 面板中，切换到 Bottom-Up 或 Call Tree 标签页，勾选“Group by: Category”，观察
Scripting、Rendering、Painting、System各类耗时占比； - 若 Scripting 占比不高但整体卡顿严重，检查是否存在大量 Off-CPU 时间（如等待 fetch 响应、localStorage 读写、或
postMessage同步等待），这时需结合 Network 和 Memory 面板交叉验证； - 对疑似内存压力问题，开启 Memory 面板录制，同时捕获堆快照与分配时间线，再对照火焰图中
gc、mark-sweep-compact等 GC 相关节点的宽度和频次。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
