pprof 火焰图：为什么自底向上读更准

拿到一张 CPU 火焰图，本能反应通常是从上往下找最宽的那一条——那是占用最多的调用栈顶。看热点没问题，但想找到“能改的地方”，方向要反过来：从下往上，看哪个分支是自己代码里的分叉点。

火焰图的方向约定

默认的火焰图是倒置的：顶部是根调用，底部是叶子。宽度代表采样占比，同一层里越宽的函数，占用的 CPU 越多。把鼠标停在某一帧上，能看到它和它父帧的占比差——这个差值，就是“这一层自己消耗的时间”。

很多人误以为最宽的叶子就是答案。但叶子往往在标准库或运行时里，比如内存分配、哈希计算、系统调用，这些改不动。真正能改的是它们上面那一层：你的代码在哪里调用了这些高频操作。

自底向上的读法

头一步，找到最宽的那个叶子，记下它的父帧。父帧就是调用入口。

第二步，沿着父帧往上走，直到遇到首个属于业务代码的帧。这个帧是“可改点”。

第三步，看这个可改点占父帧的比例，判断优化能拿回多少。如果它只占 5%，改完的整体收益也很有限。

这套读法的价值在于避免“对着标准库优化”——那种优化通常只剩换实现一条路，成本高、收益小。

三个常见的误判

一是把采样当成精确值。默认采样频率是 100 赫兹，短函数可能一次都没被采到，看到的宽度不代表真实耗时。

二是忽略 IO 等待。CPU 火焰图只反映 CPU 时间，阻塞在磁盘或网络上的部分不在图里，要看的是另一类 profile。

三是把一次采样当长期规律。不同负载下热点会变，压测环境和线上的图经常不一样。

一个更有效的组合

CPU 火焰图定位“算得多”，内存 profile 定位“分配得多”，goroutine 或线程 profile 定位“等得多”。三类图叠在一起看，才能判断瓶颈是在算、在分配，还是在等。只看一张图，容易把一个等待问题当成计算问题去优化。

采样之外的两个证据

火焰图看的是统计结果，真正定位问题还需要另一类证据：基准测试和 trace。基准测试能给出改前改后的对比，trace 能看到单次请求内部各阶段的耗时分布。三者结合，才能判断优化是否真的生效。

另一个容易忽略的点是标签。采样时可以给 profile 加标签，按请求类型、租户或接口分组，这样能看到哪类请求慢，而不是整体慢。默认的全局视图往往把长尾请求平均掉了。

还有 GC。垃圾回收的停顿会分散在各个函数里，火焰图上表现为零散的宽度，不容易看出来。看 GC trace 比看火焰图更直接。

另外，profile 采集本身有开销，线上长时间开启要评估影响，通常做法是定点开启、限定时长。

先把最慢的那类请求单独拉出来看，比盯着整体平均值更有意义。

还有一点是采样频率。默认 100 赫兹对短函数不够，频率调高能看到更多细节，开销也跟着上升。抓住可疑函数后提高频率复采一次，只跑可疑路径，噪音会小很多。

本文为行业科普分享，所述观点仅代表作者个人理解，不构成任何性能优化承诺；采样结果受负载与环境影响。