pprof 默认 HTTP 接口在 /debug/pprof/，需导入 net/http/pprof 并启动 HTTP server（如 http.ListenAndServe(“localhost:6060”, nil)），端口 6060 为惯例；若用自定义 mux，须手动注册；生产环境必须加访问控制。

pprof 默认 HTTP 接口在哪？怎么快速启用

Go 程序默认不暴露 pprof 接口，必须显式注册。最简方式是导入 net/http/pprof 包，它会自动向 DefaultServeMux 注册一组路径（如 /debug/pprof/、/debug/pprof/profile）。只要你的服务启用了 HTTP server，且未覆盖默认 mux，就能直接访问。

常见错误是只 import 却没启动 HTTP server，或用了自定义 http.ServeMux 但忘了手动注册：

import (_ "net/http/pprof" // 注意：下划线导入即可触发 init()     "net/http" ) 
func main() { go func() {http.ListenAndServe("localhost:6060", nil) // nil 表示用 DefaultServeMux }() // …… your app logic}

• 端口 选 6060 是惯例，避免和主服务端口冲突
• 如果用了自定义 mux，需手动调用 pprof.RegisterHandlers(mux)（Go 1.21+）或逐个 Handle，例如：mux.HandleFunc("/debug/pprof/", pprof.Index)
• 生产环境务必加访问控制——pprof 暴露内存布局、goroutine 栈 等敏感信息，不能放行公网

profile 类型怎么选？cpu vs heap vs goroutine

访问 http://localhost:6060/debug/pprof/ 页面会列出所有可用 profile 类型。关键 区别 不在“有没有数据”，而在“采集方式”和“适用问题”：

• profile（即 /debug/pprof/profile）：默认是 30 秒 CPU 采样，适合定位 热点 函数。它用系统信号中断执行流抓取栈，** 不阻塞程序运行 **
• heap（/debug/pprof/heap）：抓取当前堆内存分配快照，显示哪些对象占内存多、由谁分配。注意：默认是“已分配但未释放”的对象；加 ?gc=1 可触发 GC 后再采样，更反映真实压力
• goroutine（/debug/pprof/goroutine）：抓取所有 goroutine 的当前栈。加 ?debug=2 显示完整栈（含 runtime 内部），常用来查卡死、无限 wait 或 leak（比如大量 select{case 阻塞在关闭 channel 上）
• block 和 mutex 需要提前开启：在 main() 开头调用 runtime.SetBlockProfileRate(1) 或 runtime.SetMutexProfileFraction(1)，否则返回空

如何用 go tool pprof 分析火焰图？本地离线也能做

pprof 数据本身是二进制格式，必须用 go tool pprof 解析。你不需要在线看——所有分析都可离线完成：

立即学习“go 语言免费学习笔记（深入）”；

# 抓取 CPU profile（30 秒）curl -o cpu.pprof "http://localhost:6060/debug/pprof/profile?seconds=30" 
生成火焰图（需先装 graphviz）
go tool pprof -http=:8080 cpu.pprof
或直接导出 svg
go tool pprof -svg cpu.pprof > cpu.svg

• 火焰图中宽条 = 耗时长的函数调用路径，颜色深浅无绝对意义，只看宽度排序
• 默认展示的是“inuse_space”（堆内存占用），不是“alloc_objects”（分配次数）。查内存暴涨要用 -sample_index=inuse_space；查频繁小对象分配用 -sample_index=alloc_objects
• 如果看到大量 runtime.mallocgc 在顶部，说明分配热点，接着点进去看是谁在 new / make；如果 io.ReadFull 或 json.Unmarshal 占比高，可能是序列化瓶颈
• 注意单位：CPU profile 默认是毫秒级采样，但火焰图纵轴是调用栈深度，横轴才是时间占比

线上服务怎么安全地 profile？别让 pprof 拖垮服务

线上直接跑 /debug/pprof/profile?seconds=30 很危险：CPU 采样本身有开销，30 秒持续采样可能让 QPS 下降 10%~20%，尤其高并发服务。

• 优先用短采样：?seconds=5 足够捕获周期性热点，多次抓取比单次长采样更稳妥
• CPU profile 不要和 GC 同时发生——GC 期间采样失真严重。可先 curl "http://localhost:6060/debug/pprof/heap?gc=1" 触发一次 GC，稍等几秒再采 CPU
• 对 latency 敏感的服务，改用 execution tracer：go tool trace 采集更细粒度事件（goroutine 调度、网络阻塞、GC），开销比 CPU profile 小得多，但分析门槛略高
• 永远不要在容器里用 localhost 访问自己——Kubernetes Pod 内 localhost 不等于宿主机，应绑定 0.0.0.0:6060 并通过 service 名或 pod IP 访问

pprof 最容易被忽略的一点：它只告诉你“哪里慢”，不告诉你“为什么慢”。比如 sync.RWMutex.RLock 占比高，可能是读锁竞争，也可能是写锁长期未释放导致读等待——得结合 mutex profile 和代码逻辑交叉验证。