必须用带符号表的二进制文件配合 profile 才能解析函数名，否则 pprof 仅显示地址或 unknown；正确命令为 go tool pprof ./myapp cpu.out，禁用 -ldflags="-s -w"，火焰图需用 -raw 导出 folded stack 并用 flamegraph.pl 渲染。
直接用 go tool pprof 打开 profile 文件却只看到 runtime.mcall 或一堆 0x... 地址？那不是没瓶颈，是根本没解析出函数名——90% 的“定位失败”都卡在这一步。
pprof 命令必须带二进制文件才能解析函数名
Go 的 CPU profile 记录的是程序计数器（PC）地址，不是函数名。pprof 需要可执行文件里的 DWARF 符号表做地址映射。只传 cpu.out 就等于给它一张没坐标的地图。
- 错误写法：
go tool pprof cpu.out→ 输出全是[unknown]或单行 100% - 正确写法：
go tool pprof ./myapp cpu.out（./myapp是你用go build生成的二进制） - 如果是 benchmark 生成的临时二进制：
go test -bench . -cpuprofile cpu.out -o bench.test，后续必须用go tool pprof bench.test cpu.out - 验证符号是否可用：
readelf -S ./myapp | grep debug有输出，或file ./myapp显示with debug_info
构建时禁用 -ldflags="-s -w"，否则函数名全丢
发布版常加 -ldflags="-s -w" 减小体积，但这会剥离符号表和 DWARF 信息，pprof 拿不到任何源码线索。
- 开发/分析阶段务必用默认构建：
go build -o myapp main.go - 若已用 strip 构建，重编译是唯一办法；
pprof对这类二进制只能显示地址，无法关联函数或行号 - CI/CD 中建议分环境：dev/test 环境保留符号，prod 环境才用 strip，但留一份带符号的 debug 版归档备用
火焰图生成必须走 folded stack + flamegraph.pl
go tool pprof -svg 画的是调用图（callgraph），不是火焰图（flame graph）。Web UI 的「Flame graph」按钮依赖 dot，极易因环境缺失静默失败。
- 稳定路径：先导出 folded stack 文本：
go tool pprof -raw -lines ./myapp cpu.out > stacks.txt - 再用 Brendan Gregg 的
flamegraph.pl渲染：./flamegraph.pl stacks.txt > flame.svg -
-raw是关键参数，缺了它flamegraph.pl无法识别格式 - 别信
go tool pprof -http=:8080点按钮——除非你确认dot -V可用且版本 ≥ 2.40
看火焰图时盯宽度，不是高度或颜色
火焰图中每个矩形宽度 = CPU 耗时占比，高度 = 调用栈深度。优化优先级由宽决定，不是由颜色深浅或位置高低决定。
- 顶部窄、底部宽的函数块（如大量
runtime.mallocgc）说明瓶颈在内存分配，不是计算逻辑 - 中间层突然变宽的函数（比如
encoding/json.(*encodeState).marshal占满半屏），才是真实热点 - 如果某个业务函数在火焰图里又细又长，但 cum% 很高，说明它调用了大量低效子函数——这时要看
(pprof) list YourFunc定位具体哪行耗时 - 内联会影响展示：加
-gcflags="-l"关闭内联后重采样，能暴露被折叠的中间层，尤其适合排查胶水函数下的真实瓶颈
真正难的不是生成火焰图，而是让图里出现你能认出来的函数名和行号——符号表、二进制绑定、采样方式，三者缺一不可。一旦图里全是 ???，所有后续分析都是空中楼阁。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
