真实内存泄漏需满足稳定负载下heap_inuse线性增长且重启归零复现；抓heap profile须禁用?gc=1、用http接口间隔30秒采两次快照、文件名带.heap或.pb.gz后缀，再通过pprof -http比对inuse_space净增长并focus目标类型定位泄漏点。
内存泄漏在Go微服务里不是“涨了就漏”，而是heap_inuse在稳定负载下持续线性增长、重启后归零复现——只看单次/debug/pprof/heap快照，90%的情况会误判为GC假象。
怎么抓到有效的 heap 快照而不是垃圾数据
刚启动或GC频繁时抓的快照全是临时对象，根本看不出泄漏。必须等服务进入稳定高负载（比如QPS稳定在80%容量）、且MemStats.NextGC远大于MemStats.HeapAlloc时再采样。
- 线上用 HTTP 接口连续抓两次：先
wget http://localhost:6060/debug/pprof/heap -O before.heap，等至少 30 秒后再抓after.heap；文件名必须带.heap或.pb.gz后缀，否则go tool pprof可能无法识别 - 绝对不要加
?gc=1参数——它强制触发GC，会把本该长期存活的对象“刷掉”，掩盖真实泄漏点 - 本地复现更可控：在关键逻辑前后调用
pprof.WriteHeapProfile(f)，比如HTTP handler入口和出口、goroutine启动前后
为什么 top 看到 *UserConfig 占 150MB，list 却找不到分配代码
top统计的是当前驻留内存总和，list显示的是函数内所有分配（含已GC的），两者口径不同。你代码里很可能根本没写&UserConfig{}，而是通过第三方库间接创建并持久化了指针。
- 典型场景包括：
json.Unmarshal解析进全局map[string]*UserConfig但key永不删除；sync.Map.LoadOrStore("id", cfg)后忘记清理过期项；slice截取后赋给全局变量导致底层数组被长期引用 - 此时要用
go tool pprof -http=:8080 binary before.heap after.heap打开Web UI，点View → Difference，再Focus *UserConfig，才能看到谁在new它且没释放 - 调用栈里全是
runtime.selectgo或runtime.gopark？说明泄漏藏在中间层——重点查channel缓冲区、未关闭的context.WithCancel、或忘记close()的管道
如何区分 goroutine 泄漏和真内存泄漏
goroutine本身开销小（初始栈2KB），但它只要活着，就可能“钉住”大对象。比如闭包捕获了含[]byte的struct，或channel接收者一直挂着map引用——这时heap profile看不出源头，因为GC不敢动。
立即学习“go语言免费学习笔记（深入）”；
- 立刻访问
/debug/pprof/goroutine?debug=2（注意是?debug=2，不是?debug=1），它才输出完整调用栈 - 重点搜
chan receive、select、time.Sleep、http.Transport等阻塞态，尤其是重复出现的业务文件行号（如client.go:72） - 如果发现某函数启动了上千个goroutine且状态全是
IO wait或semacquire，大概率是未关闭的channel或无超时的HTTP client
pprof 默认不显示泄漏源头，得手动切指标和视图
runtime.mallocgc占比最高不是问题根源，它是所有内存分配的统一入口。真正要盯的是它调用栈上层的业务代码——谁在频繁调用make、new、append，且对象未及时回收。
- 别从
top顶部占比排序开始读，先用top -cum看累积分配量，再用list your_package.(*YourStruct).Process定位具体行号 -
go tool pprof默认显示-inuse_space（当前驻留内存），但泄漏必须看这个；若想查分配总量，得加-sample_index=alloc_space - 火焰图里大量扁平分支都指向
time.Now()或log.Printf？别优化算法，先删日志或换zap.Sugar()+条件包裹——字符串拼接和反射-heavy操作才是高频逃逸源
最常被忽略的一点：pprof本身不记录请求上下文。生产环境泄漏往往依赖真实流量特征（比如某个header触发异常缓存路径），必须把profile时间戳和访问日志对齐，再结合埋点（goroutine ID + 关键参数 + time.Now().Unix()）才能锁定根因。
