pprof 默认生成 protocol buffer 二进制文件，需用 go tool pprof 或可视化工具解析；直接 cat 或浏览器打开会乱码或报错；http 方式通过 /debug/pprof/ 各路由获取 profile，注意 block/mutex 等需显式启用；分析时需区分 alloc/inuse、space/objects，避免误判内存泄漏；采样具有概率性，低频高开销问题需结合 trace 或日志验证。
pprof 生成的 profile 文件默认是二进制格式，不是文本
很多人第一次用 go tool pprof 时发现打开的是乱码或提示“unrecognized profile format”，其实是误以为输出是可读文本。Golang 的 pprof 默认生成的是 protocol buffer 编码的二进制文件（如 cpu.pprof、mem.pprof），必须用 go tool pprof 或支持该格式的可视化工具解析。
常见错误现象：
- 直接 cat cpu.pprof 看到一堆不可读字符
- 用浏览器直接打开显示“Failed to load profile”
- go tool pprof 报错 failed to fetch profile: unrecognized profile format（通常是 URL 路径写错或服务未启用）
- 生成 CPU profile：运行时加
runtime.SetCPUProfileRate(50000)，或启动时用go run -gcflags="-cpuprofile=cpu.pprof" main.go - HTTP 服务方式更常用：在程序中导入
net/http/pprof，然后访问http://localhost:6060/debug/pprof/profile?seconds=30下载 CPU profile - 内存 profile 不需要持续采样：访问
http://localhost:6060/debug/pprof/heap即可获取当前堆快照
用 go tool pprof 分析 CPU 和内存 profile 的典型命令组合
命令本身简单，但参数顺序和 flag 含义容易混淆。关键不是“怎么跑命令”，而是“哪个命令对应什么问题”。
- 看 CPU 热点函数（火焰图基础）：
go tool pprof cpu.pprof→ 进入交互式终端后输入top10或web（需安装 graphviz） - 对比两个 CPU profile 差异：
go tool pprof --base baseline.pprof current.pprof，然后用top查看新增热点 - 查看内存分配位置（不是当前占用）：
go tool pprof --alloc_space mem.pprof；看当前存活对象用--inuse_space（默认行为） - 导出为可读文本报告：
go tool pprof -text cpu.pprof > profile.txt，适合 CI 中 grep 关键函数耗时
注意：--alloc_objects 和 --alloc_space 对应分配次数与字节数，--inuse_objects 和 --inuse_space 对应当前堆中仍存活的数量/大小——选错就看不到真正泄漏点。
HTTP pprof 服务开启后，别忽略 /debug/pprof/ 的完整路由列表
只记得 /debug/pprof/profile 和 /debug/pprof/heap 是不够的。很多性能瓶颈藏在其他子路由里，比如 goroutine 阻塞、mutex 争用、block 堆栈等。
立即学习“go语言免费学习笔记（深入）”；
-
/debug/pprof/goroutine?debug=2：查看所有 goroutine 的完整调用栈，找卡死或疯长的协程 -
/debug/pprof/block：定位 channel send/recv、锁等待等阻塞操作（需先调用runtime.SetBlockProfileRate(1)） -
/debug/pprof/mutex：查锁竞争（需设runtime.SetMutexProfileFraction(1)） -
/debug/pprof/trace：生成执行轨迹 trace 文件（go tool trace专用），比 pprof 更细粒度，但开销更大
这些 endpoint 默认不开启 block/mutex profile，必须显式设置 rate，否则返回空或提示“profile not available”。
pprof 结合基准测试（benchmark）时，profile 文件容易漏掉关键上下文
用 go test -bench=. -cpuprofile=bench.pprof 生成的 profile，只覆盖 Benchmark* 函数体内的代码。如果被测函数依赖外部初始化（如数据库连接池构建、配置加载）、或 benchmark 循环外的 setup/teardown，这些部分不会计入 profile。
- 确保
-benchmem开启，否则内存分配统计不准 - 单次 benchmark 运行太短（
ns/op极小）会导致采样不足，profile 空或失真；可用-benchtime=5s延长运行时间 - 想分析 setup 阶段？把初始化逻辑挪进
BenchmarkXxx函数内部，或改用go tool pprof http://localhost:6060/debug/pprof/profile在真实负载下抓取 - 多个 benchmark 并行跑时，profile 会混在一起；用
-run=BenchmarkOne隔离单个用例
最常被忽略的一点：pprof 的采样是概率性的，低频但高开销的操作（比如某次慢 SQL）可能根本没被捕获——这时候得靠 trace 或日志打点交叉验证。
