Go pprof CPU 图中 flat 和 cum 怎么看

看 Go 的 CPU profile 时，很多人第一眼会被 flat 和 cum 两列绕住：一个函数的 flat 很小，cum 却很大，到底是它慢，还是它调用的代码慢？其实这不是两套互相矛盾的统计，而是同一组采样在调用栈上的两种归属方式。

官方资料：https://go.dev/blog/pprof

记住一句话：flat 看“采样落在这个函数自己身上的时间”，cum 看“这个函数及其下游调用链合计承接的时间”。先用 flat 找真正做重活的内层函数，再用 cum 找应该从哪里进入这条调用链。

先把 flat 和 cum 看成两种耗时归属

CPU profile 不是给每个函数计时，而是在运行期间周期性记录当前 goroutine 的调用栈。某一刻采样点落在 parseLine，那么这次采样会让 parseLine 的 flat 增加；同一条栈上的上层函数也会在 cum 统计中承接这次采样。

因此，flat 更像“函数自己的工作量”，cum 更像“以这个函数为入口的调用子树总量”。一个请求入口通常 flat 不高但 cum 很高，因为它大部分时间在等待下游；一个真正执行解析、分配或哈希计算的内层函数，往往 flat 更有解释力。

可以把一条调用关系想成 HTTP handler -> service -> parser -> bytes.Index。如果采样停在 bytes.Index，四个节点都可能得到 cum 贡献，但只有当前工作的函数得到对应的 flat 贡献。这个视角能解释为什么同一行在两列里的数字差距很大。

用调用关系判断该看哪一列

架构上，flat 和 cum 不是“谁更准确”的竞争关系，而是内层热点与外层边界的分工。先看 top，可以发现 CPU 真正落在哪些函数自身；再看 top -cum，可以知道哪个入口承接了最大的调用树。

例如一个 ServeHTTP 的 flat 只有 1%，cum 却达到 70%，这通常说明它是请求入口，不代表 HTTP 分发本身消耗了 70% CPU。反过来，regexp.(*Regexp).doExecute 的 flat 较高，说明具体匹配工作值得继续用 list 看源码行。

这里的“入口”还要结合问题边界：如果你要决定哪个业务接口最值得拆分或限流，优先看 cum；如果你要找哪段循环、解析或序列化代码需要优化，优先看 flat。用错列，最容易把调用链的总账误判成入口函数的独占成本。

一组最小 pprof 命令如何配合

下面这组命令只展示阅读顺序。CPU profile 可以来自 go test，也可以来自服务的 pprof HTTP 入口；重点是同一份 profile 先看两种排序，再下钻到源码位置。

# 先按函数自身采样排序，寻找真正执行重活的内层函数
go tool pprof -top app cpu.prof

# 再按调用链累计采样排序，寻找承接热点的外层入口
go tool pprof -top -cum app cpu.prof

# 对某个函数展开到源码行，区分自身与下游调用
go tool pprof -list ParseRequest app cpu.prof

# 需要看调用关系时打开本地图形视图；这是分析图，不是业务运行截图
go tool pprof -web app cpu.prof

如果 profile 来自 HTTP 服务，官方文档也支持直接把 profile 地址交给 go tool pprof。实际排查时不要只复制一条最高的 cum 记录，而要把入口、内层热点和对应代码行放回同一条调用关系中。

哪些结果不适合直接下结论

第一，采样结果是近似值。短函数、极短请求或样本量太少时，flat 的百分比可能不稳定，不能把小数点后的差异当成明确回归。第二，递归和很深的调用栈会让上层累计值不完整；此时应结合 profile 的总样本量和调用关系一起判断。

第三，cum 高不等于函数本身慢。入口函数、goroutine 启动函数和框架分发函数经常天然拥有较高 cum。第四，比较优化前后的差异 profile 时，先看 flat 和 cum 的绝对变化，再看百分比；基数或总样本变化会让百分比单独失去上下文。

一个实用判断清单是：flat 高的函数是否真的属于目标业务；cum 高的入口能否继续沿调用链拆到内层；样本是否覆盖了同一类请求；最后才是改代码或改架构。这样 flat 负责回答“哪里在做功”，cum 负责回答“哪条边界承接了问题”。

常见问题

flat 为零但 cum 很高，是不是统计错了？

不一定。它可能只是一个几乎不做计算、但包住大量下游调用的入口函数。先沿 cum 对应的调用链向下看，再用 flat 找实际消耗采样的节点。

应该只看 top 还是只看 top -cum？

两者应配合使用。只看 top 容易忽略热点属于哪个请求或任务入口，只看 top -cum 又容易把外层总账当成自身成本。最小闭环是 top -> top -cum -> list。

总结：flat 是当前函数自己的采样归属，cum 是它向下调用链的累计归属。先按问题选择入口或内层视角，再用源码行和样本上下文确认优化方向。