因为net/http/pprof的init()只向http.DefaultServeMux注册路由，而Gin不使用该默认mux，故import _ "net/http/pprof"无效；需用gin-contrib/pprof.Register或手动WrapH桥接，且生产环境必须配合鉴权路由组与独立端口。
为什么 /debug/pprof 返回 404
因为 net/http/pprof 的 init() 函数只向 http.DefaultServeMux 注册路由，而 Gin 完全不使用它。只写 import _ "net/http/pprof" 是无效的——注册发生了，但你的请求根本没走到那个 mux 上。
- 最简解法：用
github.com/gin-contrib/pprof，调pprof.Register(router)，它内部已处理好桥接 - 手动桥接（不推荐但需理解）：
r.GET("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux))，注意路径必须带*pprof通配符，且不能漏掉末尾斜杠，否则重定向会失败 - 别把
pprof.Index直接塞进gin.WrapF—— 它需要处理子路径匹配，WrapH才能正确转发
pprof.Register 和 RouteRegister 的区别
pprof.Register 把所有 pprof 路由挂到根路由下，默认前缀是 /debug/pprof；pprof.RouteRegister 则要求你先建一个受保护的路由组（比如带 BasicAuth 或 header 鉴权），再把 pprof 挂进去。
- 开发环境直接用
pprof.Register(r)最快 - 生产环境必须用
pprof.RouteRegister(adminGroup, "pprof")，否则暴露/debug/pprof/heap等接口等于交出内存快照 - 自定义前缀如
pprof.Register(r, "dev/pprof")后，访问地址变成http://localhost:8080/dev/pprof/，不是重定向，是全新路径
CPU profile 里全是 runtime.futex 怎么办
这不是 bug，是采样机制在说实话：SIGPROF 信号只能捕获 goroutine 正在执行用户代码的瞬间，一旦它阻塞在 channel、锁、syscall 或 GC，就“看不见”了，于是 top 里堆满调度器底层函数。
- 压测接口至少稳定跑 1–2 分钟后再采样，避免冷启动抖动干扰
- 采样时间不少于 30 秒：
go tool pprof http://localhost:8080/debug/pprof/profile?seconds=30 - 如果业务函数仍不出现，立刻切到
/debug/pprof/goroutine?debug=2，搜索chan receive、semacquire、select，重复出现的行号（如client.go:72）极可能是泄漏点 - 火焰图里若大量扁平分支指向
log.Printf或time.Now()，优先删日志或改用zap.Sugar().Debugw加条件判断
heap profile 显示分配少但 RSS 持续上涨
/debug/pprof/heap 只反映 Go 堆内存分配，RSS（常驻内存）上涨却可能来自 mmap、cgo、未释放的 OS 资源或 Go 运行时保留的内存页——这些不会出现在 heap profile 里。
- 先查
/debug/pprof/mmap，看是否有未释放的大块 mmap 内存 - 运行
go tool pprof http://localhost:8080/debug/pprof/allocs，对比inuse_objects和alloc_objects，确认是否分配后长期未释放 - cgo 代码要检查 malloc/free 是否配对，尤其 SQLite、OpenSSL 等库的资源管理
- Go 1.22+ 可加
GODEBUG=madvise=1环境变量，让运行时更积极归还空闲内存页给 OS
