pprof 服务没起来？检查 net/http/pprof 是否已注册
go 程序默认不暴露 pprof 接口，必须手动注册。常见错误是只导入了 net/http/pprof 却没调用任何初始化逻辑，结果访问 /debug/pprof/ 返回 404。
正确做法是确保 HTTP 路由中已挂载 pprof handler：
- 若使用默认 mux：只需
import _ "net/http/pprof"（下划线导入触发 init），且程序启动了http.ListenAndServe - 若用自定义 mux（如
http.ServeMux或第三方 router）：需显式注册，例如mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))，并注意路径末尾斜杠不能省 - 生产环境常禁用默认 mux，此时仅靠下划线导入无效——这是最常踩的坑
采样不到 CPU 数据？确认程序有持续运行的 goroutine
pprof 的 CPU profile 是基于信号中断采样，要求目标进程处于“可执行”状态。如果程序启动后立刻退出、或卡在阻塞 I/O（如无输入的 fmt.Scanln）、或所有 goroutine 都在休眠（time.Sleep 后未唤醒），就几乎采不到有效样本。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 测试时用
go tool pprof http://localhost:8080/debug/pprof/profile?seconds=30，确保后台有真实负载（比如起一个for {}或定时打日志的 goroutine） - 避免在
main()结尾直接 return；加select {}让主 goroutine 持续等待 - CPU profile 对短时任务不敏感，1 秒内完成的函数很难被捕获；如需分析单次调用，改用
runtime/pprof.StartCPUProfile手动控制启停
内存 profile 显示 inuse_space 巨高？别急着优化，先看 alloc_space
pprof 内存视图有两个核心指标：inuse_space（当前堆上活跃对象总大小）和 alloc_space（整个生命周期累计分配量）。前者高可能只是缓存合理，后者高才说明存在高频小对象分配或泄漏。
排查步骤：
- 用
go tool pprof -http=:8080 http://localhost:8080/debug/pprof/heap查看火焰图，切换顶部选项卡对比inuse_space和alloc_space - 若
alloc_space持续上涨但inuse_space稳定，大概率是分配压力大，而非泄漏；优先检查[]byte、String、map初始化是否过大 - 注意 GC 频率：频繁 GC 会推高
alloc_space统计，可通过go tool pprof http://localhost:8080/debug/pprof/gc辅助判断
集成测试里跑 pprof？用 runtime/pprof 替代 HTTP 接口
单元测试或集成测试中无法依赖 HTTP server，也不能等 30 秒采样。这时应绕过 net/http/pprof，直接调用底层 API 控制 profile 生命周期。
典型写法：
func TestSomethingWithCPUProfile(t *testing.T) { f, _ := os.Create("cpu.pprof") defer f.Close() _ = pprof.StartCPUProfile(f) defer pprof.StopCPUProfile() // 执行被测逻辑 doWork() // 生成后可直接用 go tool pprof 分析 }- 务必在
StartCPUProfile后立即执行业务逻辑，避免空转引入噪声 - 内存 profile 可用
runtime.GC()+pprof.WriteHeapProfile获取快照，适合比对前后差异 - 测试中不要用
http.ListenAndServe启服务——端口冲突、goroutine 泄漏、超时难控，纯属给自己加戏
实际做 profiling 最容易被忽略的是「对照组」：同一场景下，不改代码、只换采样参数（比如从 30 秒缩到 5 秒），profile 结果可能差异极大。没有稳定复现路径和明确对比基准，pprof 数据再好看也没法定位问题。