真实内存泄漏需满足稳定负载下HeapInuse/HeapAlloc线性增长且重启归零复现；须禁用?gc=1、用HTTP接口间隔30秒采两次.heap快照，再通过pprof -http比对inuse_space净增长并Focus目标类型定位泄漏点。
直接用 pprof 抓堆快照就能定位内存暴涨源头，但光看峰值没用——得盯住 runtime.MemStats 中的 HeapAlloc 和 PauseTotalNs 变化节奏，才能判断是泄漏、抖动还是 GC 被压垮。
怎么快速确认是不是 goroutine 泄漏导致内存涨
大批量文件处理中，内存持续上涨但 goroutine 数不降，八成是 worker 没退出或 channel 没 close。常见表现：runtime: out of memory 前 goroutine 数稳定在几百上千，pprof/goroutine?debug=2 里大量状态为 chan receive 或 select 的 goroutine。
- 检查所有
for range ch循环是否配了select+ok判断，避免读 closed channel 后 panic 退出，留下未回收栈 - 确认
sync.WaitGroup的Add/Done成对，尤其在 error early return 分支里漏掉wg.Done()会导致wg.Wait()永远卡住 - 用
debug.ReadGCStats查NumGC是否停滞：如果 30 秒内NumGC没变，说明 GC 根本没触发，大概率是对象一直被引用（比如结果塞进了全局map或未清空的 slice）
大文件读取时 heap_alloc 突增，该看哪个指标
os.ReadFile 或未限长的 bufio.Scanner 会直接把整块数据 malloc 进堆，pprof/heap 里看到 runtime.mallocgc 占比超高，且 inuse_space 曲线和文件大小强相关。这时关键不是“总内存多少”，而是看 HeapAlloc 是否随任务数线性增长、以及 PauseTotalNs 是否在单次处理后陡升。
- 若
HeapAlloc每处理一个 100MB 文件就涨 100MB 且不回落 → 典型未复用缓冲区或未截断buf[:n] - 若
PauseTotalNs单次飙升到 100ms+，且NumGC频繁 → GC 正在拼命扫新分配的大对象，说明缓冲区过大（如用了 64MBmake([]byte, 64） - 用
go tool pprof -http=:8080 <binary> <heap_profile>，点开 top 看runtime.makeslice调用栈，能直接定位哪行 new 了大切片
并发 worker 池下如何避免监控失真
多个 worker 共享同一缓冲区（比如从 sync.Pool 获取），但 pprof 默认按 goroutine 统计，容易误判为“某个 worker 内存高”。真实瓶颈常在共享资源上：未 close 的 *os.File、堆积的未消费 channel 数据、或 json.Unmarshal 复用结构体时字段残留。
立即学习“go语言免费学习笔记（深入）”；
- 别只看
pprof/heap，加一行log.Printf("mem: alloc=%v, sys=%v, gc=%v", ms.HeapAlloc, ms.Sys, ms.NumGC)定期打点，观察HeapAlloc/Sys比值 —— 若长期 > 0.7，说明堆碎片或对象驻留过久 - channel 缓冲区设太大（如
make(chan string, 10000)）时，pprof不会单独标出 channel 底层数组，但runtime.makeslice会暴露；用go tool pprof -symbolize=none可绕过符号干扰直看分配点 - worker 中调外部 API 或 DB 写入时，记得在 defer 里
runtime.GC()强制触发一次（仅调试用）：如果加了之后内存回落，说明是 GC 滞后而非泄漏
真正难抓的是那种“每小时涨 5MB，三天后 OOM”的缓慢泄漏——它往往藏在复用结构体字段未清空、日志字符串拼接未限制长度、或 HTTP client transport idle conn 未关闭里。监控必须带时间维度，不能只截一张快照。
