echo中pprof返回404是因为net/http/pprof仅向http.defaultservemux注册，而echo使用独立路由树；必须手动逐个注册/debug/pprof子路径（如/goroutine?debug=2、/heap?gc=1等），并设置writetimeout避免/profile超时中断。
pprof在Echo里返回404，根本没注册上
不是Echo不支持pprof，而是net/http/pprof的init()函数只往http.DefaultServeMux里注册路由，Echo用的是自己那套echo.Echo路由树，压根不看DefaultServeMux。只写import _ "net/http/pprof"等于白干。
必须手动桥接，但别一股脑全挂——容易被中间件干扰或超时中断。推荐做法是：
- 用
e.Group("/debug/pprof")隔离路径，避免和业务路由冲突 - 逐个注册关键子路径：
/goroutine?debug=2、/block、/mutex、/heap?gc=1，不依赖pprof.Index自动分发（它在Echo里常失效） - 显式设置
e.Server.WriteTimeout = 60 * time.Second，否则/profile?seconds=30这类长请求直接被WriteTimeout掐断
goroutine堆栈里全是semacquire、chan receive，怎么定位具体行号
看到大量semacquire或chan receive，说明有goroutine卡在锁或channel上，但光看函数名没用，得锁定代码位置。关键是用?debug=2参数获取完整栈，再配合grep过滤：
- 执行
curl "http://localhost:8080/debug/pprof/goroutine?debug=2" > goroutines.txt -
grep -A 5 -B 5 "chan receive\|semacquire" goroutines.txt | grep -E "client\.go|handler\.go|service\.go"，重点盯重复出现的文件+行号 - 如果某行号高频出现（比如
client.go:72），大概率就是channel未关闭、锁未释放或select缺default分支的位置
注意：Echo中间件（如logger、recovery）可能在栈顶注入匿名闭包，导致业务代码被压到第5层以下，别只看第一行。
CPU profile里top全是runtime.futex，实际业务函数完全看不到
这不是数据出错，而是采样机制的天然限制：runtime.futex占比高，恰恰说明goroutine正卡在系统调用、锁、channel或GC上，根本没在跑你的业务代码。这时候查CPU profile毫无意义。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
正确路径是切到阻塞视角：
- 先压测稳定1–2分钟，确保流量已进入常态，再采
/block?seconds=30 - 用
go tool pprof打开后，执行top -cum，看cum列里谁在最顶——往往是阻塞源头的调用链起点 - 若
top仍无业务函数，立刻回退到/goroutine?debug=2，搜索select关键词：没有default分支的select、空case没break、channel已满却还在send，都是典型诱因
heap profile显示内存不涨，但RSS持续飙升
RSS涨而heap不涨，基本可判定是Go运行时无法回收的“外部内存”：比如Cgo调用分配的内存、mmap映射的文件、或goroutine泄漏导致的栈内存堆积。pprof的/heap只管Go堆，对这些完全不感知。
排查要绕开heap，直击根源：
- 执行
curl "http://localhost:8080/debug/pprof/goroutine?debug=2" | wc -l，对比空载和高并发时goroutine数量。翻10倍以上基本就是泄漏 - 检查所有
go func() { ... }()启动点，确认是否漏了defer cancel()、close(ch)或ctx.Done()监听 - 若用了
sync.Pool，确认Put进去的对象没持有外部引用（比如把带http.Request指针的struct放进去，会导致整个request生命周期被延长）
真正难啃的是那些不报错、不panic、但让服务缓慢失血的goroutine泄漏——它们不会触发死锁panic，却会让RSS在几小时内从200MB爬到2GB，直到OOMKilled。
