pprof HTTP接口404主因是未启动HTTP服务或未正确挂载到默认mux；CPU采样无业务函数说明goroutine空闲/阻塞；heap看存活内存，allocs看累计分配；符号缺失导致火焰图截断需关内联并保留调试信息。
pprof HTTP 接口没暴露成功，/debug/pprof/ 返回 404
最常见的情况是只写了 import _ "net/http/pprof"，但没启动 HTTP 服务，或者启动了却没挂载到能响应 /debug/pprof/ 的 mux 上。标准库的 init 函数只注册 handler 到 http.DefaultServeMux，所以必须确保你用的是它，且监听时传了 nil（即使用默认 mux）。
检查点如下：
- 确认
import _ "net/http/pprof"在main包中，且没有拼错包名 - 确认有类似
http.ListenAndServe(":6060", nil)的调用；若用了自定义 mux（如http.NewServeMux()），需手动注册：mux.Handle("/debug/pprof/", http.StripPrefix("/debug/pprof/", http.HandlerFunc(pprof.Index))) - 路径末尾必须带斜杠：
/debug/pprof/有效，/debug/pprof会 404 - 启动后用
curl -v http://localhost:6060/debug/pprof/验证，别只靠浏览器缓存
CPU profile 采样结果全是 runtime 或 syscall，看不到自己的函数
这通常说明程序在采样期间大部分时间处于空闲或阻塞状态，比如在等 I/O、channel receive、锁竞争或 sleep。CPU profile 只记录正在执行的 goroutine 栈帧，不活跃的代码不会被采到。
解决方向不是换参数，而是换视角：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先访问
/debug/pprof/goroutine?debug=1看协程数量是否异常膨胀，再查阻塞点 - 用
/debug/pprof/block（需提前调用runtime.SetBlockProfileRate(1)）定位 channel 或 mutex 阻塞源头 - 若确定是 CPU 密集型但没采到，可能是采样时间太短或负载没打上来；可加长
?seconds=60，或在压测中触发后再采 -
go tool pprof进入后输入top -cum查累计调用链，有时热点藏在间接调用里
内存分析分不清 allocs 和 heap，总以为“对象多=泄漏”
/debug/pprof/heap 默认返回的是 in-use heap（当前存活对象），而 /debug/pprof/allocs 是累计分配总量。两者语义完全不同：前者看“现在占多少”，后者看“历史上总共申请过多少”。
误把 allocs 当成泄漏指标，会导致大量误判。真实泄漏要看 heap 随时间是否持续增长，且 GC 后不回落。
- 用
go tool pprof http://localhost:6060/debug/pprof/heap，进入后输入top -cum，重点关注自己包下的类型和分配位置 - 对比两次采集：先
curl http://localhost:6060/debug/pprof/heap?gc=1强制 GC 后采一次，隔几十秒再采一次，看inuse_space是否上涨 - 若怀疑切片/Map 泄漏，用
list yourFuncName查具体行号的分配调用，注意make([]T, 0, N)中的N是否随请求累积变大
火焰图里函数名被截断或显示为 runtime.xxx，没法定位业务代码
这是符号表缺失或编译优化导致的。Go 默认开启内联（-gcflags="-l" 可禁用），部分小函数会被合并进调用方，栈帧就消失了；另外，交叉编译或 strip 二进制也会丢调试信息。
确保分析有效性，得从构建阶段控制：
- 本地调试务必用原生编译：
go build -gcflags="all=-N -l" main.go（关内联 + 关优化） - 线上服务若无法关优化，至少保留符号：
go build -ldflags="-s -w" main.go中的-s -w会删符号表，应去掉 - 用
go tool pprof -http :8080 cpu.prof启动 Web 界面时，鼠标悬停函数块才能看到完整签名；点击函数可下钻调用子树 - 如果仍显示
runtime.mcall这类，大概率是 goroutine 频繁切换，该去查/debug/pprof/goroutine或block而非死盯 CPU 图
http.HandlerFunc 占高，背后可能是下游超时重试+无界 channel+未设 context deadline 共同作用的结果。pprof 给的是证据链起点，不是终点。 
