runtime.ReadMemStats 可直接获取 HeapAlloc（当前活跃堆内存）、HeapInuse（已分配堆内存）、NumGC（累计 GC 次数）、NextGC（下轮 GC 触发目标堆大小）、LastGC（上次 GC 时间戳）及 PauseNs（最近 256 次 GC 停顿纳秒值）等真实 GC 数据。
runtime.ReadMemStats 能拿到哪些真实 GC 数据
直接调用 runtime.ReadMemStats 是获取运行时 GC 状态最轻量、最可靠的方式，但它返回的结构体字段多且命名抽象，容易误读。比如 NextGC 不是“下一次 GC 时间”，而是“下一次触发 GC 时的堆目标大小（字节）”；LastGC 是纳秒级时间戳，不是持续时间。
关键字段含义要盯住三个核心指标：
-
HeapAlloc：当前已分配且仍在使用的堆内存字节数（含未被回收的垃圾，但不含已清扫但未归还 OS 的内存） -
HeapInuse：堆中已被 mheap 分配、当前正在使用的内存（≥HeapAlloc），反映实际驻留内存压力 -
NumGC：自程序启动以来发生的完整 GC 次数（注意：不是 goroutine 数或并发标记轮次）
别把 PauseNs 数组当实时延迟看——它只保留最近 256 次 GC 的 STW 停顿纳秒值，且每次 GC 后会左移覆盖最老记录。想长期观测，必须自己定时采样并持久化。
GOGC 环境变量改了但 GC 频率没变？检查这几点
GOGC=50 并不意味着“每用掉一半堆就立刻 GC”，它控制的是「当 HeapAlloc 增长到上一次 GC 完成后 HeapInuse 的 1.5 倍时触发下一轮」。但实际是否触发，还取决于：
立即学习“go语言免费学习笔记（深入）”；
- 堆增长是否连续：如果分配后很快释放（如短生命周期对象），
HeapAlloc可能回落，GOGC条件不满足 - 是否启用了
GODEBUG=gctrace=1：它强制输出 GC 日志，但本身不改变触发逻辑 - Go 版本差异：1.21+ 对小堆（
验证方式很简单：启动时加 GOGC=1，再用 curl http://localhost:6060/debug/pprof/gc（需启用 pprof）观察是否真变频繁——很多情况下你会发现 GC 次数没涨，因为 runtime 认为“没必要”。
pprof /gc 手动触发和 runtime.GC() 的区别
两者都会强制进入一次完整的 GC 循环，但行为边界不同：
-
runtime.GC()是同步阻塞调用，会等标记+清除全部完成才返回，期间所有 goroutine 停摆（STW）；适合单元测试或调试路径中确认对象是否真被回收 -
/debug/pprof/gc是 HTTP handler，内部也调用runtime.GC()，但受 HTTP server 调度影响——如果 handler 正在写响应流，GC 可能延后几毫秒开始 - 二者都不绕过三色标记约束：即使手动触发，仍需扫描栈、全局变量、堆上所有黑色/灰色对象，不会跳过任何可达路径
线上服务慎用。尤其不要在 HTTP handler 里无条件调用 runtime.GC()——它可能让一个本该 10ms 返回的请求卡住 50ms，且无法缓解根本的内存泄漏问题。
GC 统计里最容易被忽略的“假空闲”现象
看到 HeapIdle 很高就以为内存充足？危险。Go 的 mheap 在归还内存给 OS 前，会先尝试复用：只要某段 HeapIdle 内存紧邻正在使用的 span，它就优先从那里分配新对象，而不是向 OS 申请更多页。
这意味着：
-
HeapIdle高 ≠ 实际可用内存高，可能只是碎片化严重 -
HeapReleased才是真正还给 OS 的字节数，但它只在内存长时间闲置（默认 5 分钟）后才触发 - 若
HeapInuse - HeapAlloc差值持续增大（比如 >100MB），说明大量 span 被标记为 inuse 却没被实际使用——典型征兆是大量小对象逃逸到堆，又没被及时清扫
这时候看 runtime.MemStats 不够，得结合 go tool pprof -http=:8080 binary gc 查看 span 分布热图，否则光看数字会误判内存健康度。
