pprof 需主动挂载路由且采样时机关键：未挂载导致404，空闲采样致 runtime 函数占比高；应压测中采集30秒、检查 goroutine 泄漏与锁争用、结合 trace 定位周期性问题。
pprof 不是“开了就能看出问题”的黑盒工具，它只反映你让它采集的内容；CPU 高或内存涨，90% 不是算法慢，而是 Goroutine 泄漏、锁争用、GC 频繁或日志/字符串滥用。
为什么 /debug/pprof/ 返回 404 或空白页面
根本原因不是 pprof 没装好，而是 HTTP 路由没挂上去。net/http/pprof 只做两件事：注册路由到 http.DefaultServeMux，不启动服务也不监听端口。
- 如果你用了
http.ListenAndServe(":6060", nil)，nil表示复用DefaultServeMux，此时下划线导入_ "net/http/pprof"就能生效 - 但若用了自定义
http.ServeMux、Gin/Echo 等框架，必须手动挂载：mux.Handle("/debug/pprof/", http.HandlerFunc(pprof.Index))，且路径末尾斜杠/不能省 - Gin 用户要桥接默认 mux：
r.GET("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux)) - 检查中间件是否拦截了
/debug/pprof/—— 比如 Gin 的全局Use()可能直接返回 404
抓 CPU profile 总是看到 runtime.mcall 或 runtime.futex
这不是调度器有问题，是你采样方式错了。这些函数占比高，说明真实业务代码根本没被采到。
- 必须确保采样期间程序真正在执行计算逻辑：用
curl -o cpu.pprof "http://localhost:6060/debug/pprof/profile?seconds=30"，别用默认 15 秒 - 本地开发机（尤其是 macOS）信号采样不准，优先在 Linux 环境或加
--cap-add=SYS_PTRACE的 Docker 容器里跑 - 避免空闲状态采样：压测接口、循环触发 handler、或在
main里加for i := 0; i 这类稳定负载 - 进
go tool pprof后先输top -cum，再输list 函数名，确认热点是否落在你自己的业务函数里，而不是 runtime 底层
heap profile 显示内存没涨，但 RSS 持续上升
/debug/pprof/heap 默认返回的是当前存活对象（InuseSpace），它看不出分配源头，也掩盖了 GC 前的暴涨行为。
立即学习“go语言免费学习笔记（深入）”；
- 查泄漏必须做两次对比：先请求
/debug/pprof/heap?gc=1强制 GC，记下InuseSpace；等 30 秒再请求一次，值持续上涨才可疑 - 更准的方式是看累计分配：
go tool pprof -alloc_space http://localhost:6060/debug/pprof/heap?alloc_space=1，然后top，排前三的如果是json.Unmarshal或strings.Builder.Write，就说明高频反序列化或拼接在不断 new 对象 -
sync.Pool缓存的对象不会出现在 heap profile 里，但如果Pool.New本身创建了大底层数组（比如bytes.Buffer初始 cap=64KB），仍会推高AllocSpace - 别信浏览器直接打开的文本 —— 用
web命令生成火焰图，宽而高的函数块才是真瓶颈；窄而高的 runtime 块（如runtime.mallocgc）只是结果，不是根因
goroutine 数量暴涨却找不到泄漏点
/debug/pprof/goroutine 默认只返回 running 和明显阻塞（如 chan send）的状态，大量“活着但卡住”的 goroutine 被过滤掉了。
- 必须加
debug=2参数：curl "http://localhost:6060/debug/pprof/goroutine?debug=2" > goroutines.txt，才能看到全部栈帧 - 重点搜
select {、chan receive、sync.RWMutex.RLock这类关键词，它们常对应 channel 未关闭、锁未释放、context 没 cancel - 如果发现几千个 goroutine 都卡在同一个
http.(*conn).serve下游，大概率是 handler 里忘了defer resp.Body.Close()或用了未设 timeout 的http.Client - 别只看数量，要看生命周期 —— 用
trace分析 GC STW 和 goroutine 创建节奏，确认是不是某次请求触发了不可控的 goroutine 泛滥
真正难的从来不是怎么开 pprof，而是判断该采什么、在什么时机采、以及如何把 flat% 和 cum% 的差异转化成一行可改的代码。很多问题藏在采样窗口之外，比如每小时一次的定时任务泄漏，或某个异常分支里的 go func() { ... }() 忘了加 defer。
