最稳妥启用pprof的方法是监听127.0.0.1:6060并禁止外网访问；CPU定位需用?seconds=5短采样，内存需区分--inuse_space与--alloc_objects，阻塞问题优先分析/debug/pprof/block和/trace。
怎么快速启用 pprof 并暴露到线上？
线上服务必须能随时采集 profile 数据，但不能影响主业务端口或引入安全风险。最稳妥的做法是：开一个独立监听地址（比如 :6060），只绑定 127.0.0.1 或内网 IP，并确保防火墙/ingress 不对外暴露。
代码里只需两行：
import _ "net/http/pprof"
go http.ListenAndServe("127.0.0.1:6060", nil)
注意：_ "net/http/pprof" 是副作用导入，会自动注册所有 /debug/pprof/xxx 路由到 http.DefaultServeMux；如果项目用了自定义 http.ServeMux（比如 gin/echo），就得手动注册 handler，否则访问 /debug/pprof/ 会 404。
- 别在生产环境用
":6060"（即监听所有地址），否则可能被恶意抓取 profile 数据 - 若服务已用
gin.Engine或echo.Echo，需显式挂载：router.Any("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux)) - 某些框架（如 go-zero）支持配置项一键开启，例如
Profile.Enable: true，不用手写代码
CPU 高了怎么定位热点函数？
不是一上来就跑 go tool pprof http://localhost:6060/debug/pprof/profile —— 默认 30 秒太长，线上不敢等；而且没加 ?seconds=5 容易卡住接口或被超时中断。
正确做法是先用短采样快速试探：
go tool pprof http://127.0.0.1:6060/debug/pprof/profile?seconds=5
进交互界面后立刻执行 top，看前几行的 flat%。如果发现 encoding/json.(*decodeState).object 占 40%+，基本就是 JSON 反序列化太重；如果是 runtime.mallocgc 高，说明分配频繁，得查内存而非 CPU。
-
list能看到具体哪一行耗时多，但前提是编译时没加-ldflags="-s -w"（否则丢符号，显示为(unknown)） - 用
web或svg生成火焰图需要本地装 Graphviz；没装的话，top -cum看累积调用链更实际 - 避免在压测中途采样——此时 profile 会混入大量调度器噪声；应在 QPS 稳定、CPU 持续高于 70% 时采
内存涨了到底是泄漏还是临时分配爆炸？
直接访问 /debug/pprof/heap 看的是「当前堆上存活对象」，但很多问题出在「分配太快触发 GC 频繁」，而不是内存不释放。所以得区分两个指标：
-
--inuse_space：看常驻内存（比如缓存没清、map 一直 grow） -
--alloc_objects或--alloc_space：看 30 秒内新分配了多少对象（比如循环里反复json.Marshal）
命令示例：
go tool pprof --inuse_space http://127.0.0.1:6060/debug/pprof/heap go tool pprof --alloc_objects http://127.0.0.1:6060/debug/pprof/heap?gc=1
?gc=1 强制在采样前触发一次 GC，让 --inuse_space 更干净；而 --alloc_* 不受 GC 影响，它统计的是分配事件本身。
常见陷阱：runtime.MemStats 里的 HeapAlloc 上升 ≠ 泄漏，得结合 HeapObjects 和 NumGC 一起看——如果对象数稳定但 HeapAlloc 持续涨，才是真泄漏。
goroutine 阻塞、channel 卡死、锁竞争怎么揪？
别只看 /debug/pprof/goroutine?debug=2 的文本快照——它只告诉你此刻有多少 goroutine，看不出谁在等谁。真正有用的是三个专项分析：
-
/debug/pprof/block：专抓阻塞点，比如chan receive、semacquire（mutex）、select卡住。采样后用top看最深的阻塞调用栈 -
/debug/pprof/mutex：当contention=1（默认关闭）才收集锁竞争。启动前要加：runtime.SetMutexProfileFraction(1)，否则返回空 -
/debug/pprof/trace?seconds=10：对 goroutine 生命周期做时序分析。用go tool trace打开后点「Goroutine Analysis」，能直接看到哪些 goroutineInactive, no stack trace sampled—— 这就是卡在 channel 发送、锁等待、或time.Sleep里没醒过来
特别注意：/debug/pprof/goroutine?debug=1 返回的是 goroutine 数量摘要，?debug=2 才返回全部堆栈；线上慎用 debug=2，大量 goroutine 时响应极慢甚至 OOM。
pprof 不是万能探针——它靠采样，低频问题（比如每小时卡一次的 mutex 死锁）可能漏掉；真正难搞的阻塞，得配合 trace + 日志打点 + gdb attach 三路并进。但只要记住：CPU 看 profile，内存看 heap 的两个 flag，阻塞看 block 和 trace，90% 的线上性能抖动都能当场定位。
