runtime.ReadMemStats 是最直接的入口，因其是 Go 运行时唯一推荐、稳定公开的内存统计接口，返回含 Alloc、TotalAlloc、HeapObjects 等关键字段的 MemStats 结构体，虽会触发 STW 快照但不可被 debug.ReadGCStats 或 pprof 替代。
为什么 runtime.ReadMemStats 是最直接的入口
Go 程序运行时自带内存统计能力，不需要额外依赖或 patch 运行时。runtime.ReadMemStats 是唯一推荐的、稳定公开的接口，它返回一个 runtime.MemStats 结构体，包含如 Alloc（当前已分配字节数）、TotalAlloc（历史总分配字节数）、HeapObjects（堆对象数）等关键字段。注意：该函数会触发一次 STW 的 GC 统计快照，频繁调用会影响性能，尤其在高吞吐服务中。
常见错误是误以为 debug.ReadGCStats 或 pprof.Lookup("heap").WriteTo 能替代它——前者只返回 GC 时间线，后者输出的是采样堆快照（含指针路径），无法用于实时数值监控。
- 每秒调用一次
runtime.ReadMemStats是安全阈值；更高频率建议改用runtime.SetMemoryLimit（Go 1.21+）配合告警 - 结构体字段如
Alloc是瞬时值，TotalAlloc单调递增，适合计算分配速率（差值 / 时间） - 注意单位：所有字节数字段都是
uint64，不要用int接收导致溢出
如何避免 goroutine 泄漏干扰统计结果
内存增长不等于内存泄漏，但 goroutine 持有闭包或 channel 未关闭，常导致堆对象长期存活，让 Alloc 和 HeapObjects 持续上升。单纯看 runtime.ReadMemStats 无法定位根源，必须结合 goroutine 数量和阻塞状态。
实操建议：在采集内存数据的同时，用 runtime.NumGoroutine() 获取当前 goroutine 数，并检查 debug.ReadStacks 输出中是否存在大量重复栈帧（如 select {} 或 chan receive 阻塞）。
立即学习“go语言免费学习笔记（深入）”；
- 如果
HeapObjects增长 +NumGoroutine()同步增长，大概率是 goroutine 泄漏，而非内存分配本身过载 - 避免在 HTTP handler 中启动无缓冲 channel 的 goroutine，容易因下游慢导致堆积
-
pprof.GoroutineProfile可导出活跃 goroutine 栈，比debug.ReadStacks更轻量
怎样把统计嵌入模块而不污染业务逻辑
硬编码调用 runtime.ReadMemStats 到每个 handler 或方法里，既难维护又易遗漏。正确做法是封装为可组合的中间件或指标收集器，利用 Go 的 init 阶段注册或依赖注入方式接入。
示例：定义一个 MemCollector 类型，启动时用 time.Ticker 定期采集，并通过 sync.Map 存储最近 N 次快照，供 HTTP 接口或 Prometheus exporter 拉取：
type MemCollector struct {
snapshots sync.Map // key: timestamp, value: *runtime.MemStats
ticker *time.Ticker
}
<p>func (c <em>MemCollector) Start() {
c.ticker = time.NewTicker(5 </em> time.Second)
go func() {
for range c.ticker.C {
var stats runtime.MemStats
runtime.ReadMemStats(&stats)
c.snapshots.Store(time.Now(), &stats)
}
}()
}- 不要用全局变量存储 stats，避免并发读写冲突；
sync.Map或atomic.Value更安全 - 采集间隔设为 5 秒以上，避免 STW 开销累积；若需更高精度，优先考虑
runtime/metrics包（Go 1.19+） - 暴露指标时，只返回差分值（如每秒分配字节数），而非原始
TotalAlloc，否则监控图表会出现阶梯式跳变
runtime/metrics 包相比 ReadMemStats 有什么实际差异
runtime/metrics 是 Go 1.19 引入的指标 API，提供细粒度、无 STW 的采样能力，比如 /memory/classes/heap/objects:bytes 或 /gc/heap/allocs:bytes。它不返回完整快照，而是按名称读取单个指标值，开销更低，适合高频采集。
但它不是 ReadMemStats 的替代品：前者是“指标流”，后者是“快照视图”。例如，你无法从 runtime/metrics 得到当前堆对象总数，只能得到分配/释放速率；而 ReadMemStats 的 HeapObjects 是精确瞬时计数。
- 需要实时速率（如 MB/s 分配率）→ 用
runtime/metrics - 需要诊断内存占用峰值或对象数量 → 必须用
runtime.ReadMemStats - 两者可共存：用
metrics做监控告警，用ReadMemStats做故障时的手动 dump
真正容易被忽略的是指标命名规范：runtime/metrics 的路径名区分大小写且带斜杠，写错如 /memory/heap/alloc（少了一个 s）会导致 metrics.Read 返回空值，不报错也不提示。
