HeapAlloc才是判断Go内存是否泄漏的核心指标，它反映真实业务堆内存占用；RSS等系统级指标受OS延迟回收影响大，不能直接用于泄漏判定。
GC 后内存没“下来”，不等于泄漏，更可能是操作系统或运行时的回收延迟机制在起作用。关键要分清：是应用层真泄漏，还是内存还在 runtime 或内核手里没交还。
看对指标：HeapAlloc 才是真实水位
Go 程序中，HeapAlloc（已分配且正在使用的堆内存）才是反映业务内存占用的核心指标。它不包含空闲页、栈、代码段等干扰项。如果连接断开、对象清理后，HeapAlloc 稳定在 5–10 MB 这类合理基线，说明 GC 已生效，内存被回收了——只是还没还给 OS。
相反，RSS / top 显示的值包含 HeapSys（runtime 向 OS 申请的总内存）、栈、共享库、mmap 区域等，受 Linux 内存管理策略（如 lazy reclaim、THP、page cache 混合）影响极大，不能直接用于判断泄漏。
理解两层延迟：runtime 不急着还，OS 也不急着收
Go runtime 默认采用保守释放策略：
- GC 回收对象后，内存页进入 HeapIdle 状态，但不会立刻调用
madvise(MADV_DONTNEED)归还； - 只有当
HeapIdle > HeapInuse × 阈值且持续多个 GC 周期，runtime 才尝试释放； - 即便 runtime 调用了释放，Linux 内核也可能因内存充足、未触发压力回收（如
/proc/sys/vm/vm_swappiness=0），暂不真正回收物理页。
验证是否真泄漏：三步定位法
第一步：盯住 HeapAlloc 走势
用 pprof 每隔 30 秒抓一次 heap：go tool pprof http://localhost:6060/debug/pprof/heap?debug=1
导出多份 top -cum 对比，确认 inuse_space 是否随请求增长而持续抬升。
第二步：查引用链是否断开
生成带分配栈的 heap profile：go tool pprof -alloc_space http://.../heap
重点看 alloc_objects 高但 inuse_objects 低的类型——说明对象被分配后很快丢弃，不是泄漏；若两者都高且稳定上升，再查全局 map、sync.Pool 误用、goroutine 泄漏等。
第三步：排除 OS 层干扰
检查：
• cat /proc/<pid>/smaps | awk '/^MMU/{sum+=$2} END{print sum/1024 " MB"}'</pid>（实际映射大小）
• cat /proc/<pid>/status | grep -E 'VmRSS|VmSize'</pid>
• echo 1 > /proc/sys/vm/drop_caches（仅调试，不解决根本问题）
别踩这些坑
• 不用 debug.FreeOSMemory()：强制归还会引发 STW，破坏内存局部性，生产禁用；
• 不靠 ps/top RSS 判泄漏：它波动大，受 page cache、shared memory、anon pages 影响严重；
• 不盲目调 runtime.GC()：GC 时机由 runtime 自主调度，手动触发无法加速归还，反而增加 CPU 开销；
• 压测时可临时启用 GODEBUG=madvdontneed=1（Go 1.19+），让 runtime 更积极释放，但仅限诊断，非长期方案。
