Go pprof 怎样定位 CPU 热点函数

Go pprof 定位 CPU 热点函数，核心不是先看哪个函数名字最显眼，而是先拿到能代表真实负载的 CPU profile，再用 go tool pprof 区分函数自身耗时和调用链累计耗时。官方资料入口是 https://go.dev/doc/diagnostics；如果是 HTTP 服务，也可以参考 https://pkg.go.dev/net/http/pprof。

最稳妥的顺序是：在接近真实的请求或基准负载下采样，先看 top 和 top -cum，再用 list 落到源码行，修改后用同一类负载重新采样。CPU profile 反映的是主动消耗 CPU 的时间，不等于等待 I/O 的总延迟。

• 采样入口：测试或基准用 go test -cpuprofile，服务用 HTTP profile 端点。
• 热点判断：flat 看函数自身，cum 看函数及其下游调用的累计成本。
• 结论确认：优化前后保持负载和采样方式一致，并尽量一次只采集一种会互相干扰的 profile。

先选择能代表真实负载的采集入口

如果问题出现在单元测试或基准中，直接让 go test 写出 CPU profile 最省事。下面的命令只展示采集方式，实际项目应把基准函数或测试场景换成会触发疑似慢路径的任务：

# 用接近目标场景的基准采样，避免只测初始化或空跑循环
go test -run '^$' -bench 'BenchmarkParse' -benchtime=30s -cpuprofile=cpu.prof ./...

# 使用生成的二进制和 profile 查看热点
go tool pprof ./parser.test cpu.prof

HTTP 服务则可以通过 net/http/pprof 暴露 profile。官方处理器默认挂在 DefaultServeMux；如果服务使用自定义 mux，就要显式注册对应处理器。采集期间要让请求流量覆盖真实接口，而不是只访问健康检查：

import (
    "log"
    "net/http"
    _ "net/http/pprof" // 注册 /debug/pprof/ 下的标准分析入口
)

func main() {
    go func() {
        // 诊断端口与业务端口分开，便于控制访问范围
        log.Println(http.ListenAndServe("localhost:6060", nil))
    }()
    // 这里启动业务服务，并让压测或回放流量覆盖目标请求
}

先用 top 区分函数自身成本和累计成本

打开 profile 后，先不要急着改第一行代码。top 通常更接近“哪些函数自己在消耗 CPU”，top -cum 则会把被调用函数的样本也算到上层函数。两者一起看，才能判断是某个具体循环本身慢，还是外层入口只是承载了大量下游工作：

# 进入文本交互界面，先看函数自身的 CPU 样本
go tool pprof ./app cpu.prof
(pprof) top

# 按调用链累计成本排序，寻找占据大段调用路径的入口
(pprof) top -cum

# 输出图形或网页视图前，先限定感兴趣的包，减少无关运行时节点
(pprof) focus=example.com/project
(pprof) top10

如果一个业务入口 cum 很高但 flat 很低，通常说明它把时间花在下游函数上；如果某个解析、编码、排序或循环函数的 flat 也高，就值得直接查看其实现。不要把 runtime 节点自动当成根因，它可能只是承接了业务代码造成的分配或拷贝。

用 list 和调用关系落到具体源码行

确定候选函数后，用 list 函数名 查看源码行级样本。源码行上的成本比函数名更容易对应到具体循环、字符串拼接、编码转换或容器操作；再配合 web 或调用图，就能判断热点从哪个边界进入。

# 把函数名替换成 top 中出现的候选业务函数
(pprof) list ParseRecord

# 查看调用图，确认候选函数由哪些入口调用
(pprof) web

# 退出交互界面
(pprof) quit

这里的判断链可以写成：采样入口 → profile 文件 → top/top -cum → 源码行 → 调用关系。图中的节点只是正文概念的静态对应，不代表一次未实际执行的命令已经产生了某个固定结果。

修改后用同一负载复采，不要把一次结果当结论

找到热点后，先做一个边界清楚的改动，例如减少内层循环中的重复转换、避免不必要的拷贝，或调整明确的算法路径。然后保持同一个请求回放、基准数据、采样时长和构建方式，再生成第二份 profile。只有热点位置和成本变化都能稳定复现，才适合继续扩大改动。

Go 官方诊断文档也提醒，CPU profile 本身会带来开销；精确内存剖析、阻塞剖析等工具还可能影响其他诊断数据。生产环境要先估计开销，并尽量一次只采一种主要 profile。若问题是等待数据库、网络或锁，CPU profile 可能只显示等待期间运行的少量代码，此时应换用更匹配的诊断工具。

常见问题

为什么 top -cum 找到的是 main 或 HTTP handler？

因为累计成本会包含它调用的全部下游函数。继续用 list 查看业务子函数，并用 top 看自身成本，通常就能把外层入口和真正消耗 CPU 的内层实现分开。

CPU profile 采样时间越长越好吗？

不一定。采样窗口要覆盖目标负载并避开初始化噪声，但过长会增加采集成本，也可能混入不相关流量。更重要的是前后使用同样的场景、时长和采样入口。