GlobalMemoryStatusEx 返回的内存百分比不准，是因为自行计算 (dwTotalPhys - dwAvailPhys) / dwTotalPhys × 100 会误将 Standby 等可回收内存计入“已用”，而任务管理器和系统真实负载感知依据的是 ullMemoryLoad 字段（0–100），该值由内核综合多个内存列表状态实时估算，与界面显示一致，应直接使用而非自行推算。
为什么 GlobalMemoryStatusEx 返回的内存百分比不准？
直接调用 GlobalMemoryStatusEx 后用 (dwTotalPhys - dwAvailPhys) / dwTotalPhys * 100 算百分比，结果常偏高（比如显示 95%，但任务管理器只显示 72%）。这是因为 Windows 的“可用物理内存”dwAvailPhys 不等于“未被使用的内存”——它排除了被系统缓存（Standby List）、驱动锁定页、Session 内存等非活动但可回收的内存。任务管理器显示的是“已提交内存 / 提交限制”，更贴近实际压力感知。
真正反映系统负载倾向的指标，是 ullMemoryLoad 字段：它是内核计算出的综合负载值（0–100），已考虑 Standby、Modified、Free 等多个内存列表状态，和任务管理器底部的“内存使用率”数值基本一致。
实操建议：
- 别自己算百分比，直接读
MEMORYSTATUSEX.ullMemoryLoad - 确保结构体
dwLength正确初始化为sizeof(MEMORYSTATUSEX)，否则函数返回FALSE且不填充数据 - 该函数在 Windows XP SP2+ 可用，但 Win10/11 下仍推荐使用，兼容性好且开销极低
GlobalMemoryStatusEx 必须初始化的三个字段
常见错误是只声明 MEMORYSTATUSEX ms; 就调用，导致返回 FALSE 或数据全零。Windows 要求显式告知结构体大小，并支持未来扩展字段。
立即学习“C++免费学习笔记（深入）”；
正确写法：
MEMORYSTATUSEX ms = {0};
ms.dwLength = sizeof(MEMORYSTATUSEX); // 必须！
if (GlobalMemoryStatusEx(&ms)) {
DWORD percent = ms.ullMemoryLoad; // 0–100，直接可用
}关键点：
-
{0}初始化确保所有字段清零，避免未定义值干扰 -
dwLength必须在调用前赋值，不能依赖编译器默认或后续修改 - 返回
FALSE时不要忽略，应检查是否因结构体版本不匹配或权限问题失败（极少见，但需防御）
和 GetPerformanceInfo、WMI 比有什么区别？
如果你看到别人用 GetPerformanceInfo 或 WMI 查询 Win32_OperatingSystem 的 PercentUsedMemory，要注意它们不是同一维度：
-
GlobalMemoryStatusEx：用户态轻量调用，毫秒级延迟，ullMemoryLoad是内核实时估算值，适合每秒轮询 -
GetPerformanceInfo：需psapi.lib，返回的CommitLimit和CommitTotal更偏向虚拟内存压力，对物理内存占用感知较弱 - WMI：跨进程、跨机器友好，但首次查询慢（>100ms），频繁调用易触发 COM 初始化开销和权限弹窗
除非你要做长期监控平台或需要历史趋势聚合，否则单机实时获取内存占用，GlobalMemoryStatusEx 是最稳的选择。
64 位程序下 ullTotalPhys 和 ullAvailPhys 的单位是字节，但别用它们算百分比
这两个字段确实是 64 位无符号整数，能准确表示超过 4GB 的内存总量与可用量。但正如前面所说，用它们相减再除会误把 Standby 缓存当成“已用内存”。例如某机器有 32GB 物理内存，Standby 占 8GB，ullAvailPhys 可能只有 2GB，算出来就是 94%，而实际应用可立即使用的内存远不止这些。
所以：
- 保留
ullTotalPhys用于显示总内存（如 “32.0 GB”），格式化时除以1024.0 * 1024 * 1024 - 保留
ullAvailPhys仅作参考（比如判断是否低于阈值触发告警），不参与百分比计算 - 唯一可信的百分比来源，始终是
ullMemoryLoad
这个字段设计初衷就是解决“人眼看到的内存压力”和“机器统计的已分配页”之间的语义鸿沟——它藏得不深，但容易被跳过。
