HeapAlloc持续上涨才是内存泄漏真警报，RSS升高常是runtime未归还OS的Idle内存；应每秒调用runtime.ReadMemStats监控HeapAlloc趋势，空闲期不回落即存在强引用未释放。
Go 程序内存占用持续增长，**绝大多数情况不是 GC 失效，而是对象被意外长期持有——HeapAlloc 持续上涨才是真警报，RSS 或 top 显示的内存飙升往往只是 runtime 暂未归还 OS 的 Idle 内存，别急着重启。**
用 runtime.ReadMemStats 实时盯住 HeapAlloc 趋势
这是最轻量、最直接、无需外部依赖的观测手段。关键不是看“当前值”，而是看它在业务空闲期是否回落、回落幅度是否稳定。
-
正确做法：每秒 1–2 次调用
runtime.ReadMemStats，记录ms.HeapAlloc（单位字节），绘制成时间序列图 -
危险信号：每次请求后
HeapAlloc上涨 2MB，GC 后只回落 0.3MB，且基线逐轮抬高 → 强引用未释放（如全局map[string]*BigStruct忘记delete） -
常见坑：复用同一个
runtime.MemStats变量传入多次调用 → 字段被覆盖污染；应每次新建变量：var ms runtime.MemStats runtime.ReadMemStats(&ms) fmt.Printf("HeapAlloc: %.2f MB\n", float64(ms.HeapAlloc)/1024/1024) -
注意：
HeapSys增大 ≠ 泄漏；若HeapAlloc稳定在 8MB，HeapSys却从 20MB 涨到 120MB，大概率只是 runtime 没还内存给 OS —— 这是正常行为
用 go tool pprof 定位分配源头
当 HeapAlloc 确认上涨，下一步必须知道“谁在分配”。pprof 不是截图工具，而是要对比不同时间点的堆快照，找出长期存活对象。
-
启动 pprof HTTP 接口：导入
_ "net/http/pprof"并运行http.ListenAndServe(":6060", nil) -
抓两个快照：业务低峰时执行一次：
go tool pprof http://localhost:6060/debug/pprof/heap，保存为before.prof；持续压测 5 分钟后再抓一次，保存为after.prof -
对比差异：运行
go tool pprof -base before.prof after.prof，进入交互模式后输入top→ 看inuse_space最大的函数；再输入web生成调用图 -
关键区分：
alloc_objects高 = 频繁创建小对象（可考虑sync.Pool）；inuse_objects高 = 对象长期存活（泄漏嫌疑最大）
检查 goroutine 和资源是否真“结束”
goroutine 泄漏常被误认为内存泄漏，但它会导致栈内存堆积、OS 线程数异常增长（/proc/[pid]/status 查 Threads:），并间接拖慢 GC。
立即学习“go语言免费学习笔记（深入）”；
-
查活跃 goroutine：访问
http://localhost:6060/debug/pprof/goroutine?debug=1，看是否有数百个卡在select、chan receive或net.(*conn).read—— 尤其注意日志写入、文件操作等同步阻塞调用 -
典型陷阱：自定义日志器用
os.File.Write同步写磁盘；数据库连接池未设MaxOpenConns；time.Ticker启动后没Stop() -
修复建议：所有
io.Closer类型（*os.File、*sql.DB、zlib.Reader）必须显式Close()；goroutine 启动前加 context 控制生命周期；避免在闭包中捕获大对象（data := make([]byte, 1e6); go func(){ use(data) }()）
别碰 debug.FreeOSMemory 和盲目 runtime.GC
这两个函数是生产环境“止痛药”，但会掩盖问题、引入新风险，且根本解决不了泄漏本身。
-
debug.FreeOSMemory()会强制触发 STW，并破坏内存局部性，导致后续分配更慢；它不回收对象，只尝试把HeapIdle归还 OS —— 而你真正该管的是HeapAlloc为何下不来 -
runtime.GC()无法保证内存释放，反而增加 CPU 开销；GC 频率由 runtime 自动调控，手动调用既无效也不必要 -
唯一合理场景：压测极限内存上限时，临时启用
GODEBUG=madvdontneed=1（Go 1.19+），让 runtime 更积极归还内存 —— 仅限调试，不可上线
最易被忽略的一点：**泄漏往往不在主逻辑，而在“辅助模块”——日志、监控上报、配置热加载、自定义中间件里的缓存 map。这些代码通常不走核心路径，review 时容易跳过，但一旦出问题，就是温水煮青蛙式的持续增长。**
