pprof 启动后无数据是因为默认路由注册在 http.defaultservemux，若使用自定义 mux 或框架未手动挂载则 404；cpu profile 出现 runtime.mcall 等是采样时间短或负载不足所致；top 中 flat 表示函数自身耗时，cum 表示累计耗时；线上应按需启用以降低性能影响。
pprof 启动后没数据？检查 http.DefaultServeMux 是否被覆盖
Go 默认的 pprof 路由（如 /debug/pprof/）注册在 http.DefaultServeMux 上。如果你用了自定义的 http.ServeMux 或框架（如 Gin、Echo），而没显式挂载 pprof，访问 /debug/pprof/ 就会 404 或返回空页。
实操建议：
- 用
http.ListenAndServe(":6060", nil)——nil表示复用DefaultServeMux，pprof 自动生效 - 若必须用自定义 mux，手动导入并注册：
import _ "net/http/pprof"，再调用mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index)) - 启动后 curl
curl http://localhost:6060/debug/pprof/确认页面可打开，且包含profile、trace等链接
抓 CPU profile 时为什么总是看到 runtime.mcall 或 runtime.futex？
这是典型采样时间太短或负载不足导致的噪声。pprof 的 CPU profile 是基于 OS 信号（setitimer）周期性中断采集的，默认 100Hz（每 10ms 一次）。如果程序大部分时间在休眠、等待锁或系统调用，真实业务代码没机会被采到。
实操建议：
- 确保被测代码持续运行：加循环、压测请求、或用
go tool pprof -seconds=30延长采样时间 - 避免本地空跑：CPU profile 对 I/O 密集型代码不敏感，优先在真实请求路径中触发逻辑
- 用
go tool pprof -http=":8080" http://localhost:6060/debug/pprof/profile?seconds=30直接启动可视化界面，比 raw SVG 更易识别热点函数
top 显示高占比但看不懂调用链？聚焦 flat 和 cum 两列含义
pprof 的 top 输出中，flat 是当前函数自身耗时（不含子调用），cum 是该函数及所有下游调用总耗时。CPU 瓶颈通常先看 flat 高的函数——它才是真正“干重活”的地方；而 cum 高但 flat 低的，往往是调用入口或中间件，本身不耗 CPU。
实操建议：
- 运行
top -cum查看累计耗时排序，快速定位入口函数 - 运行
top -flat（或默认 top）找真正计算密集的函数，比如bytes.Equal、json.Unmarshal、自定义的加密循环 - 用
web命令生成调用图，注意箭头粗细对应耗时比例，别只盯着顶层框 - 对疑似函数用
list 函数名查看源码行级采样，确认是哪一行在拖慢速度
线上服务不敢开 pprof？用 runtime.SetMutexProfileFraction 和按需启用更安全
默认情况下，pprof 的 goroutine、heap、mutex profile 是关闭的，但 CPU profile 开启即采集，有约 1%~5% 性能开销。线上长期开启风险不小，尤其高 QPS 服务。
实操建议：
- 不要在 main.init 中无条件启用；改用开关控制，例如读取环境变量
ENABLE_PPROF再调用http.HandleFunc - 若需分析锁竞争，才设置
runtime.SetMutexProfileFraction(1)；平时保持 0（禁用） - 用
net/http/pprof的Profile类型支持按需导出：访问/debug/pprof/profile?seconds=15仅在此刻采样 15 秒，结束后自动关闭 - 注意：CPU profile 无法在非阻塞 goroutine（如纯 channel select）中捕获，瓶颈若在调度层，得结合
go tool trace分析
真正卡住的点，往往藏在 flat 排名前三的函数里，而不是你最先怀疑的那个 service 层方法。多花 10 秒跑一次 list，比反复猜更省时间。
