pprof 必须在服务启动时注册，因 HTTP handler 需提前挂载且 profile 数据从注册起才开始采集；生产环境需保留并限制访问权限，CPU profile 应短周期多次采样，goroutine 泄漏需分析调用栈快照，内存 profile 依赖 GC 触发。
pprof 为什么必须在服务启动时就注册？
因为 pprof 的 HTTP handler（如 /debug/pprof/）需要在服务监听前挂载，否则请求会 404；更关键的是，CPU 和 goroutine 等 profile 数据从注册那一刻才开始采集——如果运行中才加，之前发生的阻塞、泄漏、高 CPU 场景就全丢了。
常见错误是只在本地开发时加，上线后注释掉或漏配。生产环境务必保留，但要限制访问权限：
- 用
http.ServeMux显式注册，避免被第三方路由库覆盖（比如 gin 默认不透传/debug路径） - 加中间件校验 IP 或 token，例如只允许内网
10.0.0.0/8访问/debug/pprof/ - 不要用
net/http/pprof的Init()—— 它只是自动注册，不可控且易被忽略
怎么安全地抓取 CPU profile 而不影响线上服务？
CPU profile 是唯一需要持续采样的类型，pprof 默认每秒采样 100 次（通过 runtime.SetCPUProfileRate(100)），但这个开销在线上高 QPS 服务里可能抬升 1–3% CPU 使用率。关键是：别用默认的 30 秒长采样。
实操建议：
- 用短周期、多次采样代替单次长采样：例如
wget "http://localhost:8080/debug/pprof/profile?seconds=5"抓 5 秒，重复 3 次，比一次 15 秒更准且扰动小 - 避开流量高峰时段，比如选在凌晨低峰期执行
- 确认
GOMAXPROCS设置合理（通常等于 CPU 核数），否则采样线程调度不准，火焰图会出现大量 “idle” 假象
goroutine 泄漏排查时，/debug/pprof/goroutine?debug=2 返回内容怎么看？
这个 endpoint 返回的是当前所有 goroutine 的调用栈快照，不是统计值。重点不是看总数，而是找重复出现的、处于非阻塞态（比如 running 或 syscall）且长时间存活的栈。
典型泄漏模式：
- 无限 for 循环没加
time.Sleep或 channel 等待，栈顶是runtime.gopark或直接是用户函数名 - channel write 阻塞在无缓冲 channel 上，栈里有
chan send+ 用户代码行号 - HTTP handler 启动 goroutine 但没做 context 取消监听，导致请求结束后 goroutine 还在跑
用 go tool pprof 加载后，执行 top -cum 查累计时间，再用 web 看火焰图，比肉眼扫文本快得多。
内存 profile 抓完为啥 go tool pprof 显示 “no samples collected”？
这是最常踩的坑：内存 profile 不是实时采集的，它依赖 GC 触发时的堆快照。如果你服务刚启动、还没触发 GC，或者用了 GOGC=off 关闭了自动 GC，/debug/pprof/heap 就永远为空。
解决办法很直接：
- 先手动触发 GC：
curl http://localhost:8080/debug/pprof/allocs（这个 endpoint 强制 dump 当前已分配对象） - 或等自然 GC 发生后，再请求
/debug/pprof/heap?gc=1（强制触发一次 GC 并采样） - 检查是否设置了
GODEBUG=madvdontneed=1，某些 Linux 内核下它会让pprof误判内存未释放
注意：/debug/pprof/allocs 统计的是累计分配量，/debug/pprof/heap 是当前存活对象——两者用途完全不同，别混用。
pprof 不是万能探针，它本身会引入可观测性开销，而真正的瓶颈往往藏在 syscall、网络延迟或外部依赖里。抓到火焰图后，第一反应不该是优化某一行 Go 代码，而是确认：这是否真是本进程的问题？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
