必须用/debug/pprof/heap?gc=1强制gc后采样获取有效heap.pprof数据，对比两次快照需用go tool pprof -base分析净增长，同时结合goroutine?debug=2定位阻塞点，否则易漏根因。
Go 内存泄漏不能靠猜，得用 pprof heap 看对象生命周期，再结合 pprof goroutine 排查阻塞点——两者不一起看，大概率漏掉根因。
怎么拿到有效的 heap.pprof 数据
直接访问 /debug/pprof/heap 拿到的是当前“驻留内存”快照（inuse_space），但泄漏常藏在“分配总量”里。比如一个对象反复创建又丢弃，inuse_space 可能稳定，alloc_space 却持续上涨。
- 用
curl -s "http://localhost:6060/debug/pprof/heap?gc=1" > heap_before.pb强制 GC 后采样，减少噪声 - 跑一段时间负载后，再抓一次：
curl -s "http://localhost:6060/debug/pprof/heap?gc=1" > heap_after.pb - 对比时加
-base参数：go tool pprof -base heap_before.pb heap_after.pb，只看净增长部分 - 别忽略
-sample_index=alloc_space：比如go tool pprof -sample_index=alloc_space heap_after.pb，再执行top查累积分配最多的函数
为什么只看 top 会误判泄漏点
top 显示的高分配函数，未必是泄漏源头——它可能只是个中间调用者。真正的问题往往在它的调用链末端，或某个全局结构体没清理。
- 执行
top -cum，看“累积分配量”，定位最重的调用路径 - 对关键函数用
list <func></func>，逐行看哪一行触发了新对象分配（比如make([]byte, n)或&Struct{}） - 重点检查：是否写入了未清理的全局
map、slice，或 channel 未关闭导致接收 goroutine 持有引用 - 注意
sync.Pool的误用：Put 了但 Get 前被 GC 回收，或 Put 的对象仍被其他地方引用，Pool 就没法复用
goroutine 泄漏和内存泄漏经常绑在一起
一个卡在 select 上的 goroutine，哪怕只占几 KB 栈空间，也可能持有几 MB 堆内存的引用，让 GC 完全无法回收——这时候 heap.pprof 里对象还在，但你找不到谁在用它。
- 先跑
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2，看输出里有没有大量重复的调用栈 - 重点关注阻塞在
chan receive、semacquire（锁）、select的 goroutine - 检查对应代码：channel 是否由调用方负责关闭？
time.Ticker是否调用了Stop()？context是否传到底层并正确监听Done()？ - 典型陷阱：
for range ch看似安全，但如果ch是无缓冲 channel 且没人关它，goroutine 就永远挂起
容易被忽略的 RSS 虚高问题
进程 RSS 内存持续涨，但 heap.pprof 里 inuse_space 很平稳？可能是内存碎片或 OS 层面没归还，不是传统意义的泄漏，但一样压垮服务。
- 用
runtime.ReadMemStats打印HeapInuse和HeapIdle：如果HeapIdle占比长期 > 40%，说明 GC 归还了内存给运行时，但运行时没还给 OS - 临时缓解可设
GOMEMLIMIT（Go 1.19+），比如GOMEMLIMIT=2G，逼 runtime 主动向 OS 释放空闲页 - 长期方案：避免高频小对象分配，改用
sync.Pool复用；或把大块数据拆成固定大小 chunk，提升内存复用率
真实泄漏从来不是单点问题，而是分配、引用、释放三个环节中至少一环断裂。pprof 给你的是证据链，不是结论——alloc_space 告诉你“谁造了它”，goroutine 告诉你“谁扣着不放”，web 图谱告诉你“怎么连起来”。缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
