runtime.MemStats.Alloc是最接近业务感知的堆内存指标，但需显式调用runtime.ReadMemStats(&ms)刷新，它仅反映GC快照中存活堆对象字节数，不包含栈、CGO或内核映射等；真实RSS应读/proc/self/status的VmRSS字段。
Go 程序里“使用的内存”没有单一答案——runtime.ReadMemStats 返回的 Alloc 是最接近业务感知的堆内存，但它不包括栈、CGO 分配、内核映射等；而系统级 RSS（实际物理内存占用）得去读 /proc/self/status。别直接拿 MemStats.Sys 当进程内存用量，它常比 RSS 大一倍以上。
怎么正确读取 Go 进程当前堆内存（Alloc）
runtime.MemStats.Alloc 表示当前堆上活着的对象字节数，是判断“应用层是否内存异常增长”的核心指标。但它不是实时值，必须显式调用 runtime.ReadMemStats 才能刷新：
- 先声明
var ms runtime.MemStats，再调runtime.ReadMemStats(&ms)—— 传指针，否则读到零值 - 别在
defer或 panic 恢复路径里调，运行时状态可能不稳定，偶尔 panic - 高频调用（如每毫秒）会拖慢程序：它虽轻量，但需等待当前 GC 结束才能返回快照
- 显示时建议除以
1024.0 * 1024.0转 MB，所有字段单位都是字节
为什么 Alloc 看起来不涨或突变
这不是 bug，是设计如此：MemStats 是 GC 周期快照，只在 GC 完成后更新（或你手动调 ReadMemStats）。常见现象和原因：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 刚分配一大块内存，
Alloc却没变：GC 还没触发，快照仍是旧的 - 监控图出现锯齿：每次 GC 后
Alloc回落，然后缓慢爬升，形成周期波动 - 和
ps aux的 RSS 不一致：RSS 包含栈、共享库、内核映射等，Alloc只是堆中存活对象 - 想验证是否真涨了？分配后手动调
runtime.GC()（仅调试用），再读Alloc，就能看到回落
怎么拿到真实进程 RSS（Linux）
如果要告警或容量评估，Alloc 不够用，得看操作系统眼中的物理内存占用（RSS）。Linux 下最准的是读 /proc/self/status 中的 VmRSS：
- 用
os.ReadFile("/proc/self/status")读取，逐行找以"VmRSS:"开头的行 -
VmRSS单位是 kB，提取数字后乘以 1024 得字节数 - 注意跳过空行、注释行；正则别跨行匹配，避免误抓其他字段
- 别用
/proc/self/statm：它字段位置固定但难读，且VmRSS更直观
容易被忽略的关键点
真正影响 OOM 的从来不止是 Go 堆：C.malloc 分配的内存、mmap 映射的大文件、大量 goroutine 的栈空间，都不会出现在 MemStats 里。生产环境若 RSS 持续上涨但 Alloc 平稳，优先查 CGO、unsafe 操作或 goroutine 泄漏——pprof 的 goroutine profile 配合 debug=2 参数才能暴露全量 goroutine 状态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
