pprof在gin/echo/chi等框架中返回404，是因为其init函数仅向http.defaultservemux注册路由，而这些框架使用自定义路由机制；必须手动桥接，如gin用r.get("/debug/pprof/*pprof", gin.wraph(http.defaultservemux))。
pprof 在 Gin/Echo/Chi 等框架中为什么访问 /debug/pprof/ 返回 404
因为 net/http/pprof 的 init() 函数只向 http.DefaultServeMux 注册路由，而 Gin、Echo、Chi 等框架都使用自定义路由机制，不共享默认 mux。
常见错误是只写了 import _ "net/http/pprof" 就以为能用 —— 这个导入确实触发了注册，但注册目标是空的 DefaultServeMux，而你的框架根本没用它。
- Gin：必须显式桥接，例如
r.GET("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux))；注意路径通配符*pprof和末尾斜杠不能省，否则重定向失败 - Echo：用
e.Group("/debug/pprof").Use(middleware.WrapHandler(http.DefaultServeMux))，或更稳妥地手动注册子路径（/debug/pprof/heap、/debug/pprof/profile等） - Chi：调用
mx := chi.NewRouter(); mx.Mount("/debug/pprof", http.HandlerFunc(pprof.Index))，不能直接chi.Router().Handle，必须用Mount - 若用
http.NewServeMux自建服务，需手动挂载：mux.Handle("/debug/pprof/", http.StripPrefix("/debug/pprof/", http.HandlerFunc(pprof.Index)))
CPU profile 采样后全是 runtime.futex 或 runtime.mcall 怎么办
这不是数据错了，而是采样机制在“如实汇报”：CPU profile 基于信号中断（SIGPROF），只捕获线程正在执行用户代码的瞬间；一旦 goroutine 阻塞在锁、channel、syscall 或 GC 上，就无法被采到，于是 top 里堆满调度器底层函数。
真正要查的不是这些运行时函数占比高，而是它们背后是否隐藏着高频争用或泄漏。
- 先确认业务逻辑是否真在跑：压测接口已稳定在目标 QPS 至少 1–2 分钟后再采样，避免启动抖动或空闲状态干扰
- 采样时长至少 30 秒：
go tool pprof http://localhost:8080/debug/pprof/profile?seconds=30；低于 15 秒基本不可信 - 如果 top 里还是看不到业务函数，立刻切到
/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 默认返回的是当前存活对象（inuse_space），而 RSS 上涨可能来自已释放但未归还操作系统的内存（如 malloc 向 OS 申请的大块内存未回收）、sync.Pool 缓存、或 goroutine 栈累积 —— 这些都不计入 heap profile。
关键不是看单次快照，而是验证是否“持续增长且不可逆”。
- 强制 GC 后再采：访问
/debug/pprof/heap?gc=1，等几秒让 GC 完成，再抓一次；连续两次间隔 2–5 分钟，对比InuseSpace是否净增 - 查分配源头：用
curl -o heap_alloc.pprof "http://localhost:8080/debug/pprof/heap?alloc_space=1"，然后go tool pprof --alloc_space heap_alloc.pprof+top，看json.Unmarshal、strings.Repeat等是否排前三 - 注意
sync.Pool：Pool 里的对象不会出现在 heap profile，但如果New函数创建了大底层数组（如bytes.Buffer初始容量设为 1MB），仍会推高AllocSpace - RSS 涨但 heap 不涨？立刻检查
/debug/pprof/heap?inuse_space和/debug/pprof/mmap（Go 1.21+），后者能暴露未归还的 mmap 区域
goroutine 数暴涨但 heap profile 看不出泄漏点
goroutine 本身开销极小（初始栈仅 2KB），但它只要活着，就可能“钉住”大对象 —— 比如闭包捕获了含 []byte 的 struct，或 channel 接收者长期持有 map 引用。GC 不敢回收这些对象，导致 RSS 上涨，但 heap profile 只显示“存活对象”，看不出谁在 hold 住它们。
这时候必须靠 goroutine 栈反推持有关系。
- 必须用
?debug=2：/debug/pprof/goroutine?debug=2输出完整调用栈；?debug=1只给统计摘要，毫无定位价值 - 重点过滤阻塞态：用
grep -A 5 -B 5 "chan receive\|select\|time.Sleep\|http.Transport"快速定位可疑 goroutine - 比对两次 dump：第一次记下 goroutine 总数和典型栈，过 30 秒再抓一次，看是否有某类栈数量线性增长（如每秒新增 10 个
handleRequest） - 常见漏点：HTTP client 未设
Timeout或Transport.IdleConnTimeout、defer 里忘了close(ch)、for-select 循环里漏了case
?debug=2 的栈和两次 ?gc=1 的对比，才是最接近真相的操作。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
