最可靠方式是Linux读/proc/meminfo取MemAvailable（内核3.14+），Windows调GlobalMemoryStatusEx取ullAvailPhys；二者语义相近但机制不同，数值差异属正常。
Linux 下用 /proc/meminfo 解析物理内存使用
Linux 没有跨版本稳定的 C++ 系统 API 直接返回内存使用率，最可靠的方式是读取 /proc/meminfo 文件并解析关键字段。这个文件实时反映内核统计的内存状态，精度高、开销低，且所有主流发行版都支持。
常见错误是直接用 MemFree 当作“可用内存”——它不包含可回收的 PageCache 和 Slab，实际可用远高于此。正确做法是用 MemAvailable（内核 3.14+），它已综合估算可立即分配的内存。
-
MemTotal：总物理内存（KB） -
MemAvailable：预估真正可用内存（KB），优先用它算使用率 -
MemFree+Buffers+Cached+SReclaimable≈ 手动估算旧内核的可用量 - 解析时注意跳过注释行和空行，字段后可能有冒号和空格，建议用
std::string::find(':')定位值起始位置
Windows 下调用 GlobalMemoryStatusEx 获取内存信息
Windows 提供了稳定且带向后兼容的 API：GlobalMemoryStatusEx，必须传入 MEMORYSTATUSEX 结构体指针，且结构体 dwLength 字段必须提前设为 sizeof(MEMORYSTATUSEX)，否则函数直接返回 FALSE —— 这是新手最常踩的坑。
该函数返回的是当前进程视角下的全局内存状态，不是进程独占内存。ullAvailPhys 对应可用物理内存，ullTotalPhys 是总物理内存，二者相除即得当前使用率。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 需包含
<windows.h>，链接kernel32.lib - 结构体必须初始化，否则
dwLength未赋值会导致调用失败 - 返回值为
BOOL，必须检查是否为TRUE，不能只看结构体字段 - 单位是字节，计算百分比时注意用
double避免整数截断
跨平台封装要注意的兼容性细节
没有标准 C++ 接口能统一 Linux 和 Windows 的内存查询逻辑，强行抽象成一个函数容易掩盖差异。比如 Linux 的 MemAvailable 是估算值，而 Windows 的 ullAvailPhys 是精确快照；又比如 macOS 需用 host_statistics + HOST_VM_INFO，完全另一套机制。
若项目确实需要跨平台，建议按 OS 分离实现，用 #ifdef 或构建系统控制编译路径，而不是试图写一个“通用”函数去适配三者。
- Linux：依赖
/proc/meminfo，无权限要求，但文件格式轻微变动（如字段名大小写）需容错 - Windows：API 稳定，但
GlobalMemoryStatusEx在 Windows XP SP2+ 才支持，旧环境需降级用GlobalMemoryStatus（精度较低） - 不要尝试用
sysconf(_SC_PHYS_PAGES)算总内存——它返回页数，且不反映当前可用状态
为什么不用 std::system 调用 free -m 或 tasklist
用 std::system 启动 shell 命令看似简单，但问题很多：启动子进程开销大、输出格式随 locale 和版本变化（如 free 在不同版本中列顺序不同）、无法捕获错误码、难以做超时控制。更严重的是，在嵌入式或容器环境中，/usr/bin/free 可能根本不存在。
相比之下，直接读 /proc/meminfo 或调用系统 API 是零依赖、确定性高、性能好。除非你只是写个临时脚本，否则不建议走 shell 调用这条路。
-
free -m输出中 “available” 列在旧版本里叫 “cached”，混淆风险高 -
tasklist /fi "pid eq 123"是查单个进程内存，不是系统总内存，容易误解需求 - 管道解析文本比二进制 API 调用更容易因空格、缩进、单位（k/M/G）出错
MemAvailable 和 ullAvailPhys 这两个字段的语义最接近，但它们底层机制完全不同：一个是内核估算，一个是硬件快照。别指望它们数值完全一致，差几个百 MB 很正常。 
