globalmemorystatusex 返回 ulltotalphys 为 0 的根本原因是未初始化 memorystatusex 结构体的 dwlength 字段，必须设为 sizeof(memorystatusex) 且结构体需零初始化，否则 api 拒绝填充数据。
为什么 GlobalMemoryStatusEx 返回的 ullTotalPhys 总是 0？
常见现象是调用后 ullTotalPhys 为 0，根本原因是没初始化 MEMORYSTATUSEX 结构体的 dwLength 字段。Windows API 要求你显式告诉它结构体大小，否则直接拒绝填充数据。
- 必须在调用前设置
memStat.dwLength = sizeof(MEMORYSTATUSEX) - 结构体变量需零初始化（
MEMORYSTATUSEX memStat{};或memset(&memStat, 0, sizeof(memStat))），避免未初始化字段干扰判断 -
GlobalMemoryStatusEx返回FALSE时，不是“没内存”，而是调用失败——此时应检查dwLength是否设对、是否在 Windows XP+ 环境运行（该函数不支持 Win2000 及更早）
如何把 ullTotalPhys 转成易读的 GB 数值？
ullTotalPhys 单位是字节，直接除以 1024 * 1024 * 1024 得到 GB 是常见做法，但要注意整数截断和浮点精度问题。实际项目中建议保留一位小数并四舍五入。
- 用
double计算：double gb = static_cast<double>(memStat.ullTotalPhys) / (1024.0 * 1024.0 * 1024.0);</double> - 如需字符串输出，避免
std::to_string直接转 double（精度失控），改用std::format（C++20）或sprintf_s控制小数位：sprintf_s(buf, "%.1f GB", gb) - 注意：32 位程序在 >4GB 物理内存机器上仍能正确读出
ullTotalPhys，因为该字段是ULONGLONG，与进程位数无关
替代方案：用 GetPhysicallyInstalledSystemMemory 更可靠？
这个函数返回的是 BIOS 报告的“物理安装容量”，和 GlobalMemoryStatusEx 的 ullTotalPhys 不同——后者是 OS 实际可用的 RAM（可能因硬件保留、PCI 映射、Secure Boot 预留等而略小）。多数监控场景应优先用 GlobalMemoryStatusEx，除非你明确需要“插了多少条内存条”的硬件视角。
-
GetPhysicallyInstalledSystemMemory返回值单位是 KB，需手动转 GB；且仅支持 Windows Vista+，WinXP 下不可用 - 它不依赖当前进程权限，但无法反映内存被系统保留的真实情况（比如某些服务器上显示 64GB，但
ullTotalPhys只有 60GB） - 若两者差值超过 5%，值得查 BIOS 设置（如 “Memory Mapped IO above 4G” 是否开启）或内核日志（
dmesg类似物，即 Windows Event Log 中的 Kernel-General 事件）
跨平台兼容性怎么办？Linux/macOS 没有 GlobalMemoryStatusEx
别硬套 Windows API 做跨平台抽象。C++ 本身不提供统一接口，务实做法是条件编译 + 各平台原生方式：
- Windows：坚持用
GlobalMemoryStatusEx（确保dwLength正确） - Linux：读
/proc/meminfo中的MemTotal:行，单位 KB - macOS：调用
sysctlbyname("hw.memsize", &size, &len, nullptr, 0)，返回值单位字节 - 不要封装成一个“GetTotalRAM()”通用函数然后到处 #ifdef——容易漏掉平台特异性错误处理（比如 Linux 文件不存在、macOS sysctl 失败）
真正容易被忽略的点：Windows 上 ullTotalPhys 是动态变化的（热插拔内存、Hyper-V 动态内存等场景），但普通桌面机几乎不会变；如果你在服务进程中长期缓存这个值，记得加定期刷新逻辑，而不是只在启动时读一次。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
