Go程序RSS高但HeapAlloc低通常不是内存泄漏，而是runtime未将空闲内存归还OS；真正需监控的是ms.HeapAlloc值是否稳定回落，配合pprof对比快照定位长期存活对象及goroutine/指针引用泄漏源。
看 HeapAlloc 而不是 top 的 RSS
Go 程序内存“看起来很高”，大概率不是泄漏，而是 runtime 没还内存给 OS。你看到 top 里 RSS 涨到 1GB，但 runtime.ReadMemStats 显示 HeapAlloc 只有 12MB？那基本可以放心——空闲内存还在 HeapIdle 里躺着，没被释放是正常行为。
- 真正要盯的是
ms.HeapAlloc：它代表当前**正在使用的堆内存字节数**，回落稳定 = 没泄漏 - 每次调用
runtime.ReadMemStats必须传新变量，别复用同一个runtime.MemStats实例，否则字段会被覆盖污染 - 加个简单循环每秒打点：
var ms runtime.MemStats runtime.ReadMemStats(&ms) log.Printf("HeapAlloc: %.2f MB", float64(ms.HeapAlloc)/1024/1024) - 危险信号：空闲期
HeapAlloc每轮 GC 后只回落一点点，基线持续抬高 → 很可能是全局map[string]*BigStruct忘了delete
用 pprof 对比 inuse_objects 找长期存活对象
确认 HeapAlloc 真在涨，下一步就得知道“谁赖着不走”。pprof 不是截图工具，关键在**对比**——单张快照看不出泄漏，两张时间差够大的快照一减，泄漏对象就浮出水面。
- 启动时加
import _ "net/http/pprof"，跑http.ListenAndServe(":6060", nil) - 低峰期抓一次：
go tool pprof http://localhost:6060/debug/pprof/heap > before.prof - 压测 5 分钟后再抓：
go tool pprof http://localhost:6060/debug/pprof/heap > after.prof - 对比命令：
go tool pprof -base before.prof after.prof，进交互后输top→ 看inuse_space最大的函数；再输web看调用图 - 注意区分：
alloc_objects高 = 频繁创建小对象（考虑sync.Pool）；inuse_objects高 = 对象长期存活（泄漏嫌疑最大）
别漏掉 goroutine 和指针引用这两个“影子泄漏源”
goroutine 泄漏常被当成内存泄漏，但它不占堆，却会拖垮 GC、耗尽栈内存、让 /proc/[pid]/status 里 Threads: 数飙升。而指针误持有（比如闭包里捕获了循环变量地址），会让本该回收的对象一直被根引用链挂着。
- 查活跃 goroutine：
curl 'http://localhost:6060/debug/pprof/goroutine?debug=1'，重点扫select{}、chan receive、net.(*conn).read这类卡住的状态 - 检查所有全局缓存（
map、slice）、日志缓冲区、连接池，确认有没有无限增长或 TTL 缺失 - 对可疑结构体指针，加日志打
fmt.Printf("%p", ptr)，看是不是多个 goroutine 共享了同一地址却没同步清理 - 测试阶段务必开
go run -race，竞态检测器能直接揪出多 goroutine 写同一指针的隐患
Benchmark 里盯紧 B/op 和 allocs/op
线上问题难复现？那就回到代码单元，用 go test -bench 把内存分配“称重”。这不是性能测试，是精准测量——每个函数调用到底偷偷分了多少内存、几次堆分配。
立即学习“go语言免费学习笔记（深入）”；
- 写 benchmark 时加
b.ReportAllocs()（虽 Go 1.8+ 默认开启，但显式写更稳） - 运行：
go test -bench=^BenchmarkYourFunc$ -memprofile=mem.out，再用go tool pprof mem.out查具体哪行在分配 - 重点关注：字符串拼接用
+=还是strings.Builder？slice 是make([]T, 0)还是预估容量make([]T, 0, N)？结构体是值传还是指针传？ - 常见陷阱：
ioutil.ReadAll读大文件直接爆内存，应改用io.Copy流式处理；json.Unmarshal返回的 map/slice 若未及时丢弃，也会撑大HeapAlloc
最易被忽略的一点：别信 debug.FreeOSMemory()。它强制归还内存，但会 STW、破坏局部性，生产环境调用等于给自己埋雷。真要验证释放行为，用 GODEBUG=madvdontneed=1（Go 1.19+）就够了，仅限调试。
