Linux 上读 /proc/meminfo 取 MemAvailable 最准，它由内核3.14+计算，已扣除不可回收内存，比 MemFree+Buffers+Cached 更可靠；macOS/Windows 需调系统API；容器中必须结合 cgroup 限制校准。
Linux 上读 /proc/meminfo 取 MemAvailable 最准
Linux 系统下，MemAvailable 是内核（3.14+）计算出的真正可分配内存，比 MemFree + Buffers + Cached 更可靠。它已扣除不可回收的 page cache、slab 等，直接反映水位压力。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.ReadFile("/proc/meminfo")读取原始内容，别依赖第三方库封装（避免隐式 fallback 到不准确字段） - 逐行扫描，用
strings.HasPrefix(line, "MemAvailable:")匹配，跳过空行和注释 -
MemAvailable值单位是 kB，需转字节：value * 1024 - 总内存用
MemTotal:字段同理解析；空闲率 =MemAvailable / MemTotal * 100.0 - 若
MemAvailable不存在（老内核），再退到MemFree，但要加警告日志
macOS 和 Windows 不能读文件，得调系统 API
macOS 没有 /proc，sysctl 查不到等价的 MemAvailable。Windows 则需 GlobalMemoryStatusEx。两者都无法靠单字段直接算“空闲率”，必须组合多个值。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- macOS 推荐用
golang.org/x/sys/unix调sysctl("hw.memsize")得总内存；可用内存需查vm.stats.vm.v_free_count、v_inactive_count等再估算——但精度有限，生产环境建议直接用gopsutil封装 - Windows 用
kernel32.dll的GlobalMemoryStatusEx，填MEMORYSTATUSEX结构体，取ullAvailPhys（物理可用）和ullTotalPhys计算比率 - 跨平台项目别硬写三套逻辑，优先用
github.com/shirou/gopsutil/mem：它内部已处理各平台差异，mem.VirtualMemory()返回的UsedPercent字段反推即可得空闲率
容器中必须检查 cgroup 限制，否则数值无意义
在 Docker/K8s 里，/proc/meminfo 仍返回宿主机总量，但进程实际能用的内存被 cgroup 限死了。只看系统空闲率会严重误判资源水位。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先检查
/sys/fs/cgroup/memory.max（cgroup v2）或/sys/fs/cgroup/memory.limit_in_bytes（v1）是否存在且不为9223372036854771712（即 “max”） - 若存在限制，空闲率应基于 cgroup limit 计算：
(limit - usage) / limit * 100.0，其中 usage 来自/sys/fs/cgroup/memory.current - Linux 5.11+ 支持
memory.stat中的memavailable字段，但兼容性差，不建议依赖 - 别用
runtime.NumCPU()或runtime.ReadMemStats()替代——前者是逻辑核数，后者只是 Go 进程堆快照
别用 runtime.ReadMemStats 算系统空闲率
runtime.ReadMemStats 返回的是当前 Go 进程的堆内存统计，和系统空闲完全无关。常见错误是看到 MemStats.Sys 就以为是“系统总内存”，其实它只是 Go 向 OS 申请过的虚拟内存总量（含未提交页），和 /proc/meminfo 的 MemTotal 毫无关系。
容易踩的坑：
-
MemStats.Alloc不实时更新，两次 GC 之间不变；高频调用ReadMemStats会触发 STW，影响服务延迟 -
MemStats.Sys包含 mmap、栈、元数据等，远大于 RSS，更不等于系统总内存 - 容器中
MemStats.Sys可能接近 cgroup limit，但这是巧合，不是设计保证
真正需要系统空闲率时，路径很明确：Linux → /proc/meminfo；macOS/Windows → 系统 API 或 gopsutil；容器 → 必须叠加 cgroup 限制校准。绕开这三层，任何“看起来像”的指标都可能误导容量决策。
