真实泄漏需满足稳定负载下HeapInuse/HeapAlloc线性增长且重启归零复现；必须间隔≥30秒采集两次以上heap快照，聚焦inuse_space而非alloc_space，排除刚启动、GC高频等干扰时机，结合goroutine分析定位闭包捕获或channel未关闭等根因。
pprof heap 快照必须在稳定负载后采集，不能刚启动就抓
刚启动的 Go 程序会预分配 runtime 结构、TLS、mcache 等，heap_inuse 和 heap_objects 天然偏高，此时采样只会看到噪声。真实泄漏要观察“请求处理完成后是否回落”——比如压测 100 次接口，等 30 秒 GC 完再抓第二份快照。
常见错误现象：go tool pprof http://localhost:6060/debug/pprof/heap 返回的数值每次访问都涨，但没确认是否随请求线性增长；或者只抓一次就下结论。
- 必须对比两次以上快照：间隔 ≥30 秒，且期间无其他干扰操作（如手动
runtime.GC()） - 重点看
heap_objects增量是否 ≈ 新建对象数，且不回落；heap_inuse持续上涨只是辅助信号 - 避免在 GC 高频触发时采样——
runtime.ReadMemStats中GC字段计数突增时暂停采集
用 -inuse_space 而不是 -alloc_space 查内存驻留问题
-alloc_space 统计所有分配过的内存总量，包含已被 GC 回收的部分，对泄漏诊断毫无价值；真正要盯的是 -inuse_space，它反映当前堆上仍存活的对象占用空间。
使用场景：你发现 *model.User 占用 75% inuse_space，但调用栈只显示 http.HandlerFunc.ServeHTTP —— 这说明它被 handler 闭包捕获了，没随请求结束释放。
立即学习“go语言免费学习笔记（深入）”；
- 命令必须带参数：
go tool pprof -inuse_space http://localhost:6060/debug/pprof/heap - Web UI 中点「Focus」输入类型名，再选「View → Call graph」才能看到实际 new 出它的位置
- 如果调用栈里出现
runtime.gopark或runtime.selectgo，优先查 channel 缓冲区、未关闭的context.WithCancel、或忘记close()的管道
goroutine 泄漏常被当成内存泄漏，先看 runtime.NumGoroutine() 是否回落
内存持续上涨，八成不是对象没回收，而是 goroutine 没退出，还钉着大对象（比如闭包捕获的 []byte 或 map[string]*User）。GC 不敢回收这些对象，导致 heap_inuse 间接上涨。
关键判断点：单次请求返回后，runtime.NumGoroutine() 数值是否回到基线；压测结束后等 30 秒，是否仍比空闲态高出一大截。
- 用
/debug/pprof/goroutine?debug=2查完整堆栈，?debug=1只给统计数，看不出卡在哪 - 堆栈中出现超长阻塞时间（如
432000s）基本就是泄漏，常见于chan receive、select无 default、time.AfterFunc闭包未清理 - 没开 HTTP server？用
runtime/pprof.Lookup("goroutine").WriteTo(os.Stdout, 2)手动 dump，第二个参数必须是2
Valgrind 报 “possibly lost” 不是泄漏，别浪费时间修
Go 程序退出时 Valgrind 显示 1,152 bytes in 4 blocks are possibly lost 是正常现象，根源是 runtime 为 M:N 调度预分配的 TLS 和线程资源，由 OS 在进程终止时统一回收，pthread_create、_dl_allocate_tls 这类调用栈完全不用管。
真正该警惕的是运行期行为：heap_objects 持续增长、goroutine 数单调上升、对象存活时间远超业务逻辑生命周期。
- Go 不兼容 Valgrind：GC、栈分裂、mmap 直接分配等机制让 Valgrind 的符号跟踪完全失效
- 只要
heap_inuse运行期不持续增长、runtime.NumGoroutine()稳定、对象存活数不异常累积，退出前未释放内存就是安全的 - 真实泄漏必须满足两个条件：长期驻留 + 不可达（如全局 map 无清理、Ticker 未 Stop、channel 未关闭）
