Go pprofCPU profile 采样结果看不到业务函数怎么办

Go 的 CPU profile 里看不到业务函数，最先不要怀疑采样器坏了。先把问题拆成两层：profile 是否真的采到了业务调用栈，以及 go tool pprof 是否拿到了采集时对应的主程序二进制。很多“只有 runtime、地址或 unknown”的情况，实际是分析端使用了另一版可执行文件，或者本地符号化没有找到原始构建产物。

官方文档：https://pkg.go.dev/runtime/pprof

保留 profile 与采集时的同一份二进制，先单独查看 profile，再显式用该二进制做本地符号化；如果仍然没有业务函数，再检查采样负载、构建裁剪和架构是否一致。

• 第一判断：profile 里的样本只有运行时函数，还是函数名存在但没有业务热点。
• 最常见修复：使用采样进程的精确二进制，而不是重新编译的“同名”文件。
• 边界：CPU profile 只反映采样窗口内正在消耗 CPU 的调用，不会凭空显示未执行的业务路径。

先分清“没有符号”和“没有业务样本”

先不要直接打开图形界面。用 profile 单独跑一次 top，观察输出中的函数名和调用层级。如果函数名能正常显示，但前几名都是 runtime、调度器或 GC 相关函数，可能是采样窗口内业务 CPU 占比很低；如果大量条目只有十六进制地址、unknown 或无法映射到函数，才优先处理符号化。

CPU profile 是按采样窗口记录“正在消耗 CPU 的路径”，睡眠、等待 I/O 或没有被请求触发的函数不会因为存在于源码里就自动出现。Go 官方文档也将 CPU profile 定义为程序主动消耗 CPU 的位置，因此先确认采样期间确实有目标业务流量。

用采集时的精确二进制重新符号化

如果 profile 是通过 go test -cpuprofile 生成的，分析时通常要把产生 profile 的测试二进制或匹配构建产物放在命令中；如果来自 HTTP 端点，则要保存提供该端点的服务二进制。文件名相同不代表构建内容相同，换过提交、编译参数、目标架构或链接方式，都可能让地址映射到错误函数。

# 先只读取 profile，确认样本是否存在以及是否已经带有函数名
go tool pprof -top cpu.prof

# 使用采集 profile 的同一份主程序做本地符号化；不要换成同名新构建物
go tool pprof -symbolize=local ./service cpu.prof

# 进入交互模式后查看热点和调用关系
go tool pprof ./service cpu.prof
# 在 pprof 提示符中执行：top、list Handler、web

pprof 会优先依据 profile 中的映射寻找二进制，也可以通过命令行直接给出主程序路径；本地符号化依赖可用的二进制和本地工具链。若二进制不在 profile 记录的路径，可以把保留的构建产物放入 PPROF_BINARY_PATH 指向的目录，或直接传入准确路径。

# 将构建产物集中放到符号化目录，便于离线分析
export PPROF_BINARY_PATH="$PWD/profiles/binaries"

# 显式指定本地符号化，避免把排查结果误判为远程服务问题
go tool pprof -symbolize=local ./profiles/binaries/service cpu.prof

检查构建裁剪、版本和架构是否匹配

把 profile 与二进制配对后仍然只有地址，重点检查三件事。第一，分析端是否拿到了采样进程的精确构建物；第二，运行环境与分析端的目标架构是否一致；第三，发布流程是否把可供 pprof 读取的 Go 符号或映射信息裁掉。不要因为两个文件都叫 service 就认为它们可以互换。

package main

import (
    "log"
    "net/http"
    _ "net/http/pprof"
)

func main() {
    // 只展示标准 pprof 端点的接入位置；生产环境应限制访问边界。
    log.Fatal(http.ListenAndServe("127.0.0.1:6060", nil))
}

如果通过 HTTP 端点采集，服务端需要在采样时仍运行着目标版本；重新部署后再拿新二进制解释旧 profile，可能出现错误映射。分析源码行时还要保留与构建对应的源码版本，因为二进制记录的是函数和源码坐标，不是完整源码副本。

用一次可追溯的采样确认修复

修复后不要只凭图形页面判断。保存四样东西：profile 文件、采集时的可执行文件、源码提交或构建标识、采样命令。先用 top 确认业务包名出现，再用 list 查看具体函数；如果需要源代码行，确保分析目录能访问与该二进制匹配的源码。

# 采样期间让目标接口持续产生真实 CPU 工作，示例时长只用于排障
curl -o cpu.prof 'http://127.0.0.1:6060/debug/pprof/profile?seconds=30'

# 用采样服务的同一构建产物分析，并把结果保存为可复现记录
go tool pprof -top ./service cpu.prof

# 继续定位某个业务函数；函数名来自上一步 top 输出
go tool pprof -list='HandleRequest' ./service cpu.prof

如果这次能看到业务函数，问题通常已经收敛到“旧 profile 缺少匹配符号化输入”或“原采样没有覆盖业务负载”。如果仍然没有，记录 go version、目标平台、构建命令和 profile 来源，先检查样本生成端，再考虑工具链或 cgo 原生符号问题。

常见问题

只运行 go tool pprof cpu.prof 可以吗？

可以先这样判断 profile 是否已有函数信息；但当需要本地符号化或源码行时，应提供采集时匹配的主程序二进制。

重新编译一个同名二进制能替代原文件吗？

不建议。必须尽量使用采集进程对应的构建产物；同名、同分支甚至同版本号都不足以证明地址映射一致。

为什么 profile 里只有 runtime？

可能是业务在采样窗口内主要等待 I/O，也可能是业务工作量太小。先确认采样期间有持续业务负载，再决定是否继续排查符号。

这类问题的关键不是反复点击 pprof 页面，而是把 profile 当作一份需要配对的诊断证据：先确认采样覆盖了目标工作，再用精确二进制完成符号化，最后用构建标识和源码版本把结论固定下来。