pprof直接访问/debug/pprof/heap易误判，因默认不触发GC，返回含临时对象的快照；必须加?gc=1强制GC后采样，对比两次inuse_space净增长，并传入二进制文件加载符号表才能准确定位泄漏。
pprof 能定位内存瓶颈，但直接访问 /debug/pprof/heap 看到的数字上涨 ≠ 内存泄漏；真正要盯的是 inuse_space 在强制 GC 后是否持续增长，且必须对比两次采样。
为什么 /debug/pprof/heap 返回的数据常误导人
默认请求 /debug/pprof/heap 不触发 GC，返回的是「当前堆中所有已分配但尚未被复用的内存块」快照，包含刚分配完还没来得及回收的临时对象。这会导致 inuse_space 看似很高，实则只是 GC 周期未到。
- 必须加
?gc=1参数：强制运行一次 GC 后再采样，例如curl "http://localhost:6060/debug/pprof/heap?gc=1" -
inuse_space才是关键指标：它代表 GC 后仍存活的对象占用内存，持续上涨才说明有泄漏 -
alloc_space高只说明分配频繁，比如高频 JSON 序列化或字符串拼接，不等于泄漏 - 避免单次快照判断：至少间隔 30 秒以上采集两次，观察净增量
go tool pprof 分析 heap profile 必须传二进制文件
否则 top 输出全是 runtime.mcall 或十六进制地址（如 0x456789），根本看不到业务函数名——因为 Go 的 heap profile 只记录内存地址，没有符号表就无法映射。
- 错误做法：
go tool pprof http://localhost:6060/debug/pprof/heap - 正确做法：
go tool pprof ./myapp http://localhost:6060/debug/pprof/heap?gc=1 - 验证是否成功：进入交互后输入
top，第一列应显示如main.ProcessRequest这类函数名，而非空白或 runtime 函数 - 若用
go run启动服务，先go build -o myapp .，再运行./myapp &，最后用二进制分析
泄漏源头不在 heap profile？立刻查 /debug/pprof/goroutine?debug=2
很多“内存涨”本质是 goroutine 泄漏：一个活着的 goroutine 会钉住它闭包里引用的所有对象（比如大 buffer、map、HTTP response body），导致 GC 不敢回收——heap profile 里看不到这些对象的分配源头，但 goroutine 列表会暴露阻塞点。
立即学习“go语言免费学习笔记（深入）”；
-
?debug=1只返回统计摘要，?debug=2才输出完整栈帧，必须用这个 - 重点搜索：
chan receive、semacquire、select、net/http.(*persistConn).readLoop等阻塞态 - 重复出现的行号（如
client.go:72）就是高危点：可能是未设超时的 HTTP client、没 close 的 response.Body、或无缓冲 channel 的发送方一直等待 - 如果发现某 handler 启动了数百个状态为
IO wait的 goroutine，基本可断定是资源未释放
火焰图里全是 log.Printf 或 time.Now() 怎么办
这不是 CPU 瓶颈，而是日志/时间戳滥用导致的内存压力：每次调用都 new 字符串、拼接、分配 []byte，累积成堆内存暴涨。
- 别优化算法，先删日志：压测时关掉 debug 日志，或用
zap.Sugar().Debugw("msg", "key", value)替代log.Printf - 加条件包裹：如
if cfg.Debug { log.Printf(...) }，避免无意义分配 - 检查
strings.Builder或bytes.Buffer是否反复 new：优先复用或从sync.Pool获取 - 火焰图里扁平分支越宽，说明该调用越“热”；大量并行窄分支指向同一函数，往往是高频小分配的典型特征
真正难排查的不是函数慢，而是谁在“钉住”内存——goroutine 栈比 heap profile 更早暴露泄漏路径，而 ?gc=1 和二进制符号表是让 pprof 说人话的前提。
