Go 的 go tool pprof 在分析 CPU profile 时必须显式传入可执行文件（binary），否则无法解析符号和函数调用栈，导致 profile 显示为空或仅有 flat 时间而无函数调用信息。
go 的 `go tool pprof` 在分析 cpu profile 时必须显式传入可执行文件（binary），否则无法解析符号和函数调用栈，导致 profile 显示为空或仅有 flat 时间而无函数调用信息。
在 Go 性能分析中，CPU profile（.prof 文件）本身不包含符号表、函数名或调用关系信息——它只记录采样时的程序计数器（PC）地址和时间戳。真正将这些地址映射为可读的函数名、行号及调用栈，依赖于编译生成的可执行文件中的调试符号（DWARF）和符号表。
因此，当你运行：
go tool pprof --text prof
pprof 缺少目标二进制，只能显示“flat”总耗时（即所有采样点的汇总时间），但无法解析任何函数名或调用路径，输出自然只剩一行 1.91s of 1.91s total，看似“空”，实则是符号解析失败。
✅ 正确做法是显式提供已编译的可执行文件（即你的程序 binary）作为第一个参数：
go install . go tool pprof --text miniprofile prof
? 注意：miniprofile 是 go install 后生成的可执行文件名（默认位于 $GOPATH/bin/ 或模块模式下的 ./bin/），需确保其与 profile 文件由同一构建过程产生（即未重新编译、未 strip 符号）。若使用 go build -o myapp .，则应使用 go tool pprof --text myapp prof。
运行正确命令后，你将看到清晰的调用栈（示例输出节选）：
1.91s of 1.91s total ( 100%)
flat flat% sum% cum cum%
1.91s 100% 100% 1.91s 100% main.do_something
0 0% 100% 1.91s 100% main.main
甚至可通过 --web 生成火焰图，直观查看递归深度与热点分布。
⚠️ 补充注意事项：
- 不要 strip 符号：避免使用 -ldflags="-s -w" 构建，否则会移除调试信息，导致 pprof 无法解析函数名；
- profile 时长要足够：本例中 do_something 执行极快（微秒级），建议添加 time.Sleep(2 * time.Second) 或增大递归深度+循环，确保采样有足够数据；
- Linux/macOS 均适用：该问题与操作系统无关，是 pprof 工具的设计约束；
- Go 1.6+ 行为一致：从 Go 1.3 引入 runtime/pprof 起，此机制始终如此，非版本 Bug。
总结：Go CPU profiling 不是“开箱即用”的黑盒，而是profile 数据 + 二进制符号的协同分析。牢记 go tool pprof [binary] [profile] 这一固定范式，即可解锁完整的函数调用链、热点定位与深度优化能力。
