pprof服务未启动是因未注册路由，需显式导入并挂载；采样失败因无持续负载或时间过短；分析需用go tool pprof命令；线上启用须限访问、限流、禁高危接口。
pprof 服务没启动？检查 net/http/pprof 是否已注册
Go 的 pprof 不是开箱即用的独立服务，它依赖手动挂载到 HTTP 路由。常见错误是只导入了 net/http/pprof 包却没调用其 Init() 或没注册 handler，导致访问 /debug/pprof/ 返回 404。
正确做法是显式注册——最简方式是在主 HTTP server 上调用 http.HandleFunc 或使用 http.DefaultServeMux：
import _ "net/http/pprof"
func main() {
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()
// 后续业务逻辑...
}
注意：_ "net/http/pprof" 的空白导入会自动调用 init()，向 http.DefaultServeMux 注册路由；但如果你用了自定义 http.ServeMux 或 gin/echo 等框架，必须手动挂载：
-
router.GET("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux))（Gin） - 或直接
mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))
采样不到数据？确认程序正在运行且有真实负载
pprof 的 CPU profile 默认是「采样式」，需要程序持续运行并执行代码才能捕获栈帧。刚启动就立刻 curl /debug/pprof/profile，大概率拿到空 profile 或报 profile: no samples collected。
关键点：
- CPU profile 需要至少 30 秒默认采样时长（可通过
?seconds=5缩短，但太短易漏） - 内存 profile（
/debug/pprof/heap）是快照，可随时抓，但需触发 GC 才反映真实分配压力 - 若程序很快退出（如 CLI 工具），必须在退出前显式调用
runtime.GC()再抓 heap，否则看到的是初始状态
示例命令（采集 10 秒 CPU profile）：
curl -o cpu.pprof "http://localhost:6060/debug/pprof/profile?seconds=10"
看懂 profile 输出：别直接打开 .pprof 文件
下载下来的 cpu.pprof 或 heap.pprof 是二进制格式，双击打不开，也不该用文本编辑器硬读。真正分析靠 go tool pprof 命令行工具。
常用组合：
-
go tool pprof cpu.pprof进入交互式终端，输入top10看耗时 Top 函数 -
go tool pprof -http=:8080 cpu.pprof启 Web 界面，生成火焰图（Flame Graph） -
go tool pprof --alloc_objects heap.pprof查对象分配次数（不是内存大小）
注意：go tool pprof 默认解析的是「CPU 时间占比」，而 heap profile 默认展示的是「当前存活对象」（inuse_space），如要看历史总分配量，得加 --alloc_space。
线上环境开启 pprof 的风险点
pprof 接口暴露过多信息，线上不设防等于裸奔。典型风险：
- 未鉴权：任意人可访问
/debug/pprof/goroutine?debug=2看全部 goroutine 栈，泄露业务逻辑和中间件调用链 - 未限流：高频抓取 CPU profile 会显著拖慢程序（尤其高并发服务），
profile本身要停顿所有 P 执行采样 - 路径未收敛：有些团队把
/debug/pprof挂在公网入口，甚至配合反向代理暴露出去
最小防护建议：
- 绑定到内网地址（如
127.0.0.1:6060），禁止监听0.0.0.0 - 用中间件做基础 IP 白名单或 Basic Auth（哪怕只允许运维机器访问）
- 生产环境禁用
/debug/pprof/goroutine?debug=2和/debug/pprof/trace，这两类开销最大
真要长期监控，优先考虑导出指标到 Prometheus + Grafana，而不是让 pprof 成为常驻接口。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
