火焰图是性能分析工具生成的调用栈可视化图表，x轴表示采样频次（非时间），y轴表示调用栈深度，顶层为叶子函数，需垂直分析调用链；chrome中需在performance面板勾选“record javascript cpu profile”后录制操作，再切换至flame chart标签页查看。
火焰图不是动效，也不是 CSS 动画——它是性能分析工具生成的调用栈可视化图表。直接拿 background: linear-gradient 去“画”火焰图，只会得到一张假图，完全无法反映真实 CPU 耗时分布。
火焰图在 Chrome DevTools 里怎么打开
打开 DevTools → Performance 面板 → 点击左上角录制按钮（●）→ 操作页面 → 停止录制 → 等待解析完成 → 切换到 Bottom-up 或 Call Tree 下方的 Flame Chart 标签页。注意：必须勾选 Record JavaScript CPU Profile，否则火焰图里只有渲染线程，没有 JS 调用栈。
- 没看到火焰图？检查是否误点了
Memory或Lighthouse面板 - 火焰图一片空白？确认录制时页面有 JS 执行（比如点了按钮、触发了 fetch）
- 图里只有几个扁平色块？说明采样时间太短，延长操作时间或手动加
performance.mark()辅助定位
怎么看懂 X 轴和 Y 轴的含义
X 轴不是时间轴，而是“采样出现频次”的水平展开——每个函数块的宽度 = 它在所有采样帧中被捕捉到的次数比例。Y 轴才是关键：顶层是正在执行的函数（叶子函数），往下逐层是它的直接调用者，一直到最底下的 anonymous 或 setTimeout 入口。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 别按从左到右读——要垂直看调用链。比如某宽块在第 3 层，它上面那层是谁，再上面是谁，才能定位瓶颈源头
- 同一层多个同名函数块？说明该函数被不同路径多次调用，需分别点开看父级上下文
- 函数名带
:195这类数字？那是源码行号，点击可跳转到 Sources 面板对应位置
如何快速定位性能瓶颈
先找最宽的块，再顺藤摸瓜往上查——不是看颜色，不是看位置，就是盯宽度。例如 run (gevent/threadpool.py:195) 占 83.37%，那它父级如果是 acquire_with_timeout，就说明线程池争用严重；如果父级是 dispatch_request，就要检查 Flask 路由里有没有同步阻塞操作。
- 右键点击可疑函数 →
Copy call stack，粘贴到编辑器里反向梳理逻辑流 - 双击函数块 → 自动跳转到 Bottom-up 视图，显示“该函数自身耗时”和“含子调用总耗时”，区分是它自己慢，还是它调用的别人慢
- 按住
Shift+ 拖拽鼠标框选某段火焰区域 → 只保留该时间段的调用栈，排除干扰
为什么火焰图里看不到自己的函数
常见原因有三个：代码未执行、被 V8 内联优化掉了、运行在 Web Worker 或 iframe 里但没开启对应采样。尤其注意：DevTools 默认不采集 iframe 内 JS，需手动勾选 Capture settings → Record in all frames；Worker 需单独打开其调试面板并启用 profiling。
- 本地开发时用了
eval或模板字符串拼接函数？V8 可能拒绝为其生成符号信息，火焰图里显示为<anonymous></anonymous> - 用 Webpack 打包且没配
devtool: 'source-map'？函数名会变成./src/index.js这种路径，但行号仍可定位 - 函数执行太快（console.time() 手动打点验证
火焰图真正的门槛不在“怎么画”，而在“怎么读准调用链”。一个宽块可能藏在第 5 层，而它的真正病根在第 1 层某个被反复调用的工具函数里——漏掉这一层，优化就只是隔靴搔痒。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
