火焰图是按调用栈深度和采样频次定位CPU热点的工具，宽度表时间占比，高度表调用深度，颜色仅作区分；需结合top-down与bottom-up视图分析调用路径与源头瓶颈。
火焰图不是“看图说话”，而是按调用栈深度和采样频次定位热点的工具。Go 生成的火焰图（通常来自 pprof + go tool pprof -http 或导出 SVG）本质是“横向堆叠的调用栈快照”，宽度 = CPU 时间占比，高度 = 调用深度，颜色无语义（仅区分函数块）。
怎么看懂函数名和调用关系
火焰图中每个矩形代表一个函数，横坐标是时间轴（非真实时间，是采样分布），纵坐标是调用栈层级。顶部函数是叶子函数（正在执行的最内层），底部是入口函数（如 main.main 或 http.HandlerFunc.ServeHTTP）。
- 宽条 = 这个函数在采样中出现频率高 → 占用 CPU 时间多，优先关注
- 窄条但堆得高 = 深层调用链，可能某中间函数只是“转发”，真正耗时在它下面的叶子函数
- 函数名带
.pcdata、.symtab或十六进制地址？说明没提供可执行文件路径给go tool pprof，导致符号未解析 —— 必须补上二进制路径才能看到真实函数名 - 匿名函数显示为
main.func1、http.(*ServeMux).ServeHTTP等，注意括号里的接收者类型，这是判断是否在某个结构体方法中执行的关键线索
为什么 top-down 和 bottom-up 视图都得看
go tool pprof 的 Web 界面默认展示的是“flat”或“top-down”视图，但火焰图本身天然适合 bottom-up 分析：从顶部宽条往回追溯调用链，能直接看到“谁在调用这个热点”。而 top-down 则帮你确认“这个热点是否被高频路径触发”。
- 顶部一个宽条
runtime.mallocgc？说明内存分配密集 → 配合pprof -alloc_space或-inuse_space查分配源头 - 底部是
net/http.serverHandler.ServeHTTP，中间一长条json.Marshal占满宽度？说明 HTTP handler 里序列化成了瓶颈，不是网络或路由问题 - 同一函数在多个调用路径下都出现（比如
strings.ReplaceAll出现在三个不同 handler 中）？说明它是通用热点，值得抽离优化或换算法
容易忽略的采样偏差和陷阱
火焰图反映的是“采样结果”，不是精确计时。Go 默认 CPU profile 采样频率是每 ~10ms 一次，这意味着极短函数（time.Sleep、channel receive）不会被 CPU profile 捕获 —— 它们压根不占 CPU 时间。
立即学习“go语言免费学习笔记（深入）”；
- 没看到明显热点？可能是 I/O 或锁等待主导，该切到
blockprofile 或mutexprofile 查看 - 火焰图几乎全平（所有函数一样窄）？说明采样率太低或程序大部分时间在休眠/等待，CPU profile 不适用
- 用
go tool pprof -http启的服务，浏览器打开后火焰图空白？检查是否漏了-symbolize=remote（当 profile 来自远程服务且本地无二进制时），或确认go version与生成 profile 的 Go 版本一致（否则报unrecognized profile format） - SVG 导出后文字模糊、缩放失真？别用浏览器直接放大，用矢量图查看器（如 Inkscape）或导出为 PDF
火焰图真正的难点不在“怎么画”，而在“画出来之后，如何把宽条映射回你代码里那几行 for 循环或 channel 操作”。它不告诉你“为什么慢”，只告诉你“哪里花的时间最多”；下一步永远要回到源码，结合上下文、数据规模、并发模型去验证猜测。
