pprof 默认仅注册路由不启动服务，需显式调用 http.listenandserve 或手动挂载到自定义 servemux；cpu 采样需足够时长（20–30秒）并避开启动噪音，注意内联影响及 flat/sum 区分，线上可安全使用但应避免图形界面持续拉取。
pprof 启动后访问不到 /debug/pprof/ 路径
默认情况下，net/http/pprof 只是注册路由，不自动启动 HTTP 服务。很多人加了 import _ "net/http/pprof" 就以为能直接打开网页，结果 404。
- 必须显式启动一个 HTTP server，哪怕只监听本地：
http.ListenAndServe("localhost:6060", nil) - 如果用了自定义
http.ServeMux（比如mux := http.NewServeMux()），得手动把 pprof 路由挂上去：pprof.Handler("profile").ServeHTTP或更简单地用mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index)) - 生产环境别暴露
localhost:6060到外网；临时调试可加-addr=":6060"参数，但上线前务必关掉或加白名单
采样时长太短导致 top 看不到真实热点
CPU profile 是概率采样，不是全量记录。默认每秒采样 100 次（即采样频率 100Hz），如果程序跑得太快、或者只采样几秒，pprof 很难抓到稳定耗时函数。
- 用
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30至少采 20–30 秒，尤其对吞吐型服务 - 避免在刚启动或请求刚进来时立刻采样——GC、初始化、连接池建立等噪音会干扰判断
- 如果 CPU 占用忽高忽低，建议用
curl -s "http://localhost:6060/debug/pprof/profile?seconds=30" > cpu.pprof保存下来反复分析，而不是依赖实时 web 界面
top 显示的函数名带 [inline] 或根本对不上源码
Go 编译器会内联小函数，pprof 展示时可能把调用栈“压平”，导致你看到的是内联后的父函数，而非真正耗时的子逻辑。
- 编译时加
-gcflags="-l"关闭内联（仅调试用）：go build -gcflags="-l" -o app ./main.go -
pprof默认按“累加时间”排序，但真正想看“本函数自身耗时”，得用top -cum或在交互式界面输入top -cum，再配合list 函数名查看源码行级分布 - 注意区分
flat（本函数执行时间）和sum（包含子调用）——CPU 瓶颈通常先盯flat高的函数
线上服务不敢开 pprof 怕影响性能
pprof CPU 采样本身开销极低（纳秒级 hook），只要不频繁触发或长时间采集，对 QPS 过万的服务影响几乎不可测。真正要小心的是内存 profile 或 goroutine dump 的误用。
- CPU profile 开销约 0.5%–2%，实测中多数服务无感；可先在一台实例上开 30 秒观察监控曲线
- 避免在高峰期用
go tool pprof -http=":8080" ...启图形界面——它会持续拉取数据，可能加重负载；推荐用命令行导出 + 本地分析 - 如果服务本身已用
pprof.Register自定义指标，注意别重复注册同名 profile，否则runtime/pprof.WriteTo可能 panic
pprof 不是黑盒魔法，它只反映「采样时刻正在运行的 goroutine」。如果你的瓶颈在系统调用阻塞（比如磁盘 I/O、锁竞争）、或是 GC 频繁，CPU profile 里反而可能看不到明显热点——这时候得切到 /debug/pprof/block 或 /debug/pprof/goroutine?debug=2 配合看。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
