快速启用 pprof http 接口需先启动独立调试服务（如 localhost:6060），并确保 import _ “net/http/pprof” 在 main 包中触发自动路由注册；若用自定义 mux 则须手动挂载 /debug/pprof/ 路径，且生产环境必须加访问控制。
怎么快速启用 pprof HTTP 接口
go 程序要能被 go tool pprof 采集，第一步不是写命令，而是让程序“暴露数据”。最常用、最稳妥的方式就是启动一个独立的 HTTP 服务，并挂载 net/http/pprof 的路由。
常见错误是只写了 import _ "net/http/pprof"，却没启动 HTTP 服务；或者把 pprof 挂在了主业务端口（比如 :8080）且用了自定义 http.ServeMux，但忘了手动注册路径，导致访问 /debug/pprof/ 返回 404。
- 必须确保
import _ "net/http/pprof"在main包中执行（下划线导入会触发包内init()，自动向http.DefaultServeMux注册路由） - 启动一个单独 goroutine 监听调试端口，推荐用
localhost:6060，避免和业务端口冲突：go func() { log.Fatal(http.ListenAndServe("localhost:6060", nil)) }() - 若用了自定义 mux（如
mux := http.NewServeMux()），不能依赖下划线导入，得手动注册：mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))注意路径末尾的
/不能少 - 生产环境务必加访问控制，比如用反向代理限制 IP，或在 handler 中加 BasicAuth ——
/debug/pprof/可直接看到所有 goroutine 栈、内存分配详情，属于敏感接口
CPU profile 采样为什么总是“抓不到热点”
CPU 分析默认采样 30 秒 wall-clock 时间，但它只对正在运行（not sleeping/not blocked）的 goroutine 计数。如果你的程序大部分时间在等网络 I/O、channel receive 或 time.Sleep，top 列出来的就可能是 runtime.futex 或 runtime.usleep 这类系统调用，而不是你自己的业务函数。
这不是 pprof 失效，而是采样目标错了 —— 你需要的是“真正消耗 CPU 的路径”，不是“卡在哪”的路径。
立即学习“go语言免费学习笔记（深入）”；
- 先确认程序是否真在忙：发几个请求让它跑起来，再立刻采集；空转时采样毫无意义
- 别只看
top，进交互界面后输入top -cum查看调用链累计耗时，有时瓶颈藏在深层子调用里 - 如果程序确实 IO 密集，改用
go tool pprof http://localhost:6060/debug/pprof/block（需提前调用runtime.SetBlockProfileRate(1)）定位阻塞源头 - 采样时间不够？加
?seconds=60手动延长，但 URL 必须用引号包裹：go tool pprof "http://localhost:6060/debug/pprof/profile?seconds=60"，否则 shell 会把?当通配符解析
heap 和 allocs profile 到底该看哪个
go tool pprof http://localhost:6060/debug/pprof/heap 默认抓的是 inuse_space（当前堆上还活着的对象占用内存），而 http://localhost:6060/debug/pprof/allocs 抓的是自启动以来的总分配量（含已 GC 掉的）。两者目的完全不同。
查泄漏，盯 inuse_space；查 GC 压力大、对象创建太猛，才看 allocs。很多人一上来就跑 allocs，发现 strings.Builder.Write 占比高，就以为是它的问题 —— 其实那是正常行为，只要 inuse_space 不持续涨，就不是泄漏。
- 怀疑泄漏？先记下初始值：
curl -s "http://localhost:6060/debug/pprof/heap?debug=1" | grep "inuse_space"，执行可疑操作（比如反复调用某个 API），再查一次，看差值 - 想定位谁在疯狂 new 对象？用
go tool pprof http://localhost:6060/debug/pprof/allocs，然后top -cum找分配最多的调用链 - 对比两次 heap profile：先下载两个快照
curl -o base.pprof "http://localhost:6060/debug/pprof/heap"和curl -o cur.pprof ...，再用pprof -base base.pprof cur.pprof突出增长部分 - 注意：火焰图里
flat是函数自身耗时/分配，sum是含子调用的累计值；优化优先看flat高且逻辑可简化的函数，别盲目优化sum高但只是“路过”的中间层
离线分析时为什么看不到源码行号
go tool pprof 生成的火焰图或 list 输出里显示函数名但不显示具体哪一行，通常是因为没提供编译后的二进制文件。profile 文件本身不包含源码映射信息，它只记录符号地址；只有把 profile 和原始 binary 一起喂给 pprof，才能还原到 main.go:42 这样的位置。
线上环境一般禁用 HTTP 调试端口，只能靠离线分析，这时候 binary 缺失就成了高频盲区。
- 采集时就存好 binary：构建时用
go build -o myapp .，保留这个myapp文件，别用go run临时跑 - 分析本地 profile 文件时，显式带上 binary：
go tool pprof myapp cpu.pprof，不是go tool pprof cpu.pprof - 如果 binary 已丢失，又没开
-gcflags="-m"留下逃逸分析日志，基本无法回溯源码 —— 所以建议 CI 构建产物里固定存一份 stripped 后的 binary + profile 符号表 - 短生命周期 CLI 工具？改用
runtime/pprof手动写入：f, _ := os.Create("cpu.pprof"); pprof.StartCPUProfile(f); defer pprof.StopCPUProfile()，同样需要 binary 才能精准定位
pprof 不是点开网页就能出答案的仪表盘，它是一把解剖刀：用错角度切不到病灶，用力过猛还会污染样本。最常被跳过的一步，其实是确认“此刻程序真的在干你想分析的事”。