用 runtime.readmemstats 检测内存泄漏需在 gc 后采样 alloc 值，结合时间窗口（如30秒/次、连续5次涨超5%）分析趋势，并同步监控 goroutine 数与 gc 频率，避免误判波动和 goroutine 泄漏。
用 runtime.ReadMemStats 捕获内存基线
长期运行服务是否泄漏，不能靠肉眼盯 RSS，得靠程序自己定期快照堆内存。Go 的 runtime.ReadMemStats 是最轻量、最可靠的入口——它不依赖外部工具，也不触发 GC 副作用。
关键点：必须在 GC 完成后读，否则 Alloc 和 TotalAlloc 会包含待回收垃圾，造成误判。所以实际操作要先调 runtime.GC()，等几毫秒再读（GC 是阻塞的，但 runtime.GC() 返回时已基本完成）。
- 每次采集前加
runtime.GC()+time.Sleep(1 * time.Millisecond) - 重点关注
MemStats.Alloc（当前堆分配字节数），不是Sys或HeapSys - 避免在测试中频繁打印日志或创建字符串，它们会干扰堆统计
写一个带时间窗口的泄漏判定逻辑
单次增长没意义，得看趋势。比如每 30 秒采一次，连续 5 次 Alloc 都上涨 >5%，才报警——这比固定阈值靠谱得多。
容易踩的坑是直接比绝对值：某次 Alloc 从 12MB 到 15MB 看似涨了 25%，但如果刚处理完一批大文件，这是正常波动。必须结合业务节奏设计窗口。
立即学习“go语言免费学习笔记（深入）”；
- 用 slice 存最近 N 次的
MemStats.Alloc值，每次新数据 push 到末尾，超长就切掉头 - 计算相邻两次差值的百分比，过滤掉
delta （1MB）的微小变化 - 判定条件示例：
if current > baseline*1.05 && current-baseline > 2*1024*1024
避免 goroutine 泄漏干扰内存判断
很多“内存涨”其实是 goroutine 没退出，持续占着栈内存（默认 2KB 起）。这类问题 runtime.ReadMemStats 不会直接暴露，但会让 MemStats.HeapInuse 慢慢爬升，且 runtime.NumGoroutine() 居高不下。
真实服务里，goroutine 泄漏比堆泄漏更常见，尤其用了 time.AfterFunc、http.TimeoutHandler 或未关闭的 channel 监听。
- 每次内存采样时，同步记下
runtime.NumGoroutine() - 如果 goroutine 数稳定上涨，优先检查所有
go func() { ... }()是否有阻塞等待 - 用
debug.ReadGCStats辅助看 GC 频率是否异常下降（说明对象活得太久）
在测试中模拟长期运行场景
单元测试跑几秒没用。得让被测代码在线程里跑够几分钟，并注入可控负载。别用 time.Sleep 堵主线程——那只是“停着”，不是“运行”。要用 for 循环+定时器驱动真实工作流。
典型错误是测试里启了个 goroutine 做轮询，但没等它真正跑几轮就结束了，结果数据全是噪声。
- 用
time.NewTicker(30 * time.Second)触发采样，用time.After(5 * time.Minute)控制总时长 - 被测逻辑必须是可中断的：每个循环开头检查
ctx.Done()，避免测试卡死 - 测试结束前强制调一次
runtime.GC()，再读最终值，排除 GC 滞后影响
复杂点在于，真实泄漏往往只在特定路径触发，比如某个 HTTP handler 的 panic 恢复后忘了关 stream，这种得靠压力测试+pprof 交叉验证。单纯靠周期采样只能发现明显趋势，抓不住毛刺型泄漏。
