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"
)
<p>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" <h1>生成火焰图（需先装 graphviz）</h1><p>go tool pprof -http=:8080 cpu.pprof</p><h1>或直接导出 svg</h1><p>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 和代码逻辑交叉验证。
