pprof 能抓到内存膨胀是因为它采样所有存活对象的分配栈，可定位具体函数和行号，而 runtime.MemStats 仅提供 Alloc、HeapAlloc 等快照值，无法反映持续分配行为。
pprof 为什么能抓到内存膨胀，而不是只看 runtime.MemStats
因为 runtime.MemStats 只给快照，比如 Alloc、HeapAlloc 的当前值，但看不出“谁在持续分配”“哪段代码反复 new 对象”。pprof 的 heap profile 是采样堆上**所有存活对象的分配栈**（默认开启 net/http/pprof 时是按采样率抓，不是全量），能定位到具体函数和行号。
关键点：必须让程序跑起来并有实际内存压力，否则 go tool pprof http://localhost:6060/debug/pprof/heap 拿到的可能是空或失真的 profile。常见错误是刚启动就立刻抓 —— 这时大部分对象还没积累，看不出泄漏路径。
- 启动服务时加
_ "net/http/pprof"，确保/debug/pprof/路由可用 - 用
curl -s "http://localhost:6060/debug/pprof/heap?gc=1"强制 GC 后再采样，避免短期对象干扰 - 如果怀疑泄漏，连续采样两次（间隔 30s+），用
go tool pprof -diff_base对比增长部分
怎么区分是内存泄漏还是 GC 压力大
看 pprof 的 heap 和 goroutine + allocs profile 组合判断。单纯 heap 高，不等于泄漏；如果 heap 随时间线性上涨且 go tool pprof -inuse_space 显示某结构体占比稳定上升，才是泄漏信号。
allocs profile（/debug/pprof/allocs）反映的是“累计分配量”，适合查高频小对象创建（比如循环里 make([]byte, 1024)）。而 heap 是“当前存活”，两者结合才能分清：是对象没被回收（泄漏），还是刚分配完就被 GC 掉但频率太高（GC 瓶颈）。
立即学习“go语言免费学习笔记（深入）”；
- GC 瓶颈典型现象：
runtime.GC在top里占比高、GOGC设得太低导致频繁触发、pprof的goroutineprofile 显示大量runtime.gcBgMarkWorker - 内存泄漏典型现象：
go tool pprof -inuse_objects显示某个 struct 实例数持续增加，且调用栈固定指向某 handler 或 middleware - 别依赖
GODEBUG=gctrace=1的日志做定量分析——它只告诉你 GC 发生了，不告诉你为什么慢
框架集成时容易漏掉的 pprof 配置点
很多 Golang 框架（如 Gin、Echo、Fiber）默认不暴露 /debug/pprof，或者路由前缀被中间件拦截（比如 JWT 验证中间件拦掉了所有未认证请求，包括 pprof）。更隐蔽的问题是：HTTP 服务监听地址不是 localhost:6060，而是 :8080，但 pprof 默认注册在 DefaultServeMux，如果框架自己用了独立的 http.ServeMux 或直接传 nil，pprof 就不会生效。
- Gin 用户要显式注册：
gin.Default().GET("/debug/pprof/*pprof", gin.WrapH(http.DefaultServeMux)) - Echo 用户需手动挂载：
e.GET("/debug/pprof/*pprof", echo.WrapHandler(http.DefaultServeMux)) - Fiber 用户注意：
app.Use("/debug", func(c *fiber.Ctx) error { return c.Next() })不能省，否则 pprof 路由被跳过 - 生产环境务必加访问控制——至少用
http.HandlerFunc包一层 Basic Auth，别裸露 pprof
用 go tool pprof 分析时最常卡住的命令参数
很多人执行 go tool pprof 后卡在交互式 prompt，输 top 没反应，或者 web 打不开图。根本原因是 profile 数据本身没包含符号信息（比如用 go build -ldflags="-w -s" 去掉了调试信息），或者采样时没带 -seconds 参数导致数据不足。
- 抓 heap profile 必须加
?seconds=30（如/debug/pprof/heap?seconds=30），否则默认只采样 1 秒，样本太少无法聚合 - 分析时优先用
go tool pprof -http :8081 your_binary heap.pb.gz，比交互式更直观；如果报 “could not find symbol”，说明二进制被 strip 过，重编译去掉-w -s -
list命令查具体函数时，别直接输函数名——要输完整路径，比如list github.com/xxx/yyy.(*Z).Do，否则找不到 - 想看对象大小分布？用
go tool pprof -inuse_space，不是-inuse_objects；后者只数数量，前者才体现内存占用
真正难的从来不是跑通 pprof，而是确认你看到的 top 函数确实是业务瓶颈，而不是框架内部临时 buffer。多对比不同负载下的 profile，盯住 delta，而不是绝对数值。
