pprof需正确集成、采样和符号解析三者协同；HTTP端点404因未向DefaultServeMux注册或未手动挂载；CPU profile需同时提供二进制文件才能解析函数名；heap profile需对比多次快照判断泄漏；火焰图中cum高而flat低说明瓶颈在下游调用。
pprof 不是“开了就能看到瓶颈”的开关，它需要正确集成、采样和符号解析三者协同——缺一不可。大多数人卡在第二步或第三步，导致看到的 top 输出全是 100% 占比、无函数名、无调用栈。
pprof HTTP 端点注册失败：为什么访问 /debug/pprof/ 404？
最常见原因是没走默认路由注册路径，尤其在使用自定义 http.ServeMux 时。_ "net/http/pprof" 的 init() 函数只向 http.DefaultServeMux 注册 handler，如果你用了 http.NewServeMux() 却没手动挂载，端点就不存在。
验证方式：启动后执行 curl http://localhost:6060/debug/pprof/，返回 404 就说明没注册成功。
- 用默认 mux：确保
http.ListenAndServe(":6060", nil)第二个参数为nil（即用DefaultServeMux） - 用自定义 mux：必须显式添加所有 pprof 路由，例如：
mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))、mux.Handle("/debug/pprof/profile", http.HandlerFunc(pprof.Profile))等 - 生产环境建议加访问控制，比如用中间件校验 IP 或 Basic Auth，避免暴露敏感内存/协程快照
go tool pprof 分析 CPU profile 时 top 全是 100%：符号表缺失
这是线上调优最高频的误操作：只传 profile 文件，不传二进制文件。Go 的 CPU profile 采集的是程序运行时的内存地址，没有二进制文件，go tool pprof 就无法把地址映射回函数名，只能显示为匿名帧（anonymous frame），结果就是 flat 总和 100%，但看不到任何真实函数。
典型错误命令：go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
立即学习“go语言免费学习笔记（深入）”；
正确做法必须同时提供二进制：
- 对
go run启动的服务：先go build -o myapp .，再./myapp &，最后go tool pprof myapp http://localhost:6060/debug/pprof/profile?seconds=30 - 对
go test：用go test -cpuprofile cpu.out -o benchmark.test .，然后go tool pprof benchmark.test cpu.out - 验证是否加载成功：进入交互模式后输入
top，若第一列出现函数名（如main.CPUHeavyFunc）且占比合理，说明符号已解析；若只有runtime.mcall或空白行，说明仍失败
heap profile 显示 inuse_space 持续上涨，但 runtime.GC() 后不降：真泄漏还是假阳性？
/debug/pprof/heap 默认返回的是「当前堆中存活对象」的快照（inuse_space），但它不等于内存泄漏。很多情况只是 GC 还没触发，或对象还在强引用链中。
判断泄漏要对比两个时间点：
- 先抓一次：
curl "http://localhost:6060/debug/pprof/heap?debug=1" > heap1.txt（文本格式看原始统计） - 等几分钟、跑完一批业务逻辑后，再抓一次：
curl "http://localhost:6060/debug/pprof/heap?debug=1" > heap2.txt - 重点看
HeapInuse和HeapObjects是否持续增长，且runtime.GC()后仍不回落 - 更可靠的方式是用
go tool pprof对比：go tool pprof -base heap1.pb.gz heap2.pb.gz，它会高亮新增分配热点
注意：allocs profile（/debug/pprof/allocs）看的是累计分配量，适合找高频小对象分配点（如循环里反复 new struct），和泄漏无关。
火焰图里 cum 值远大于 flat：该优化哪一层？
火焰图中 cum（累计耗时）高而 flat（自身耗时）低，说明瓶颈不在函数本身，而在它调用的下游——比如一个 flat=0.5% 但 cum=85% 的 http.HandlerFunc，真正耗时的是它里面调用的数据库查询、JSON 序列化或外部 HTTP 请求。
此时不要急着优化这个 handler，而是用 list 命令展开看它的源码热区：list http.HandlerFunc，再顺藤摸瓜找 cum 高的子调用。
- 常见陷阱：看到
runtime.mallocgccum很高，别直接去改内存分配，先查是谁在频繁调用它——大概率是字符串拼接、切片扩容或未复用对象 - 如果
cum高的节点是第三方库（如github.com/json-iterator/go），优先检查你传给它的输入是否过大或结构嵌套过深 - 火焰图颜色深浅只反映样本密度，不代表绝对时间；宽度才代表相对耗时比例，别被红色误导
