最可靠方案是Windows用WMI查Win32_ComputerSystemProduct.UUID、Linux读/sys/class/dmi/id/product_uuid、macOS用IOPlatformUUID；三者均需校验格式、清洗大小写及全0值，并结合厂商信息识别虚拟机以增强可靠性。
Windows下用WMI查询Win32_ComputerSystemProduct.UUID
Windows没有统一的“硬件UUID”标准，但多数主板在固件（UEFI/BIOS）中写入了 Win32_ComputerSystemProduct.UUID，这是最接近硬件级唯一标识的字段。直接读取注册表或文件不可靠（可能为空或被虚拟化干扰），必须走WMI。
常见错误是用 GetVolumeInformation 或硬盘序列号替代——这些属于存储设备层级，不是整机硬件UUID，且跨盘/重装后易变。
- 需链接
comsuppw.lib并初始化COM（CoInitializeEx(nullptr, COINIT_MULTITHREADED)） - WQL查询语句必须为：
"SELECT UUID FROM Win32_ComputerSystemProduct"，字段名大小写敏感 - 返回值是16字节的十六进制字符串（如
"00000000-0000-0000-0000-000000000000"），注意去掉中间短横再转二进制时要补零 - 虚拟机（VMware/VirtualBox）通常返回固定值或全零，需额外判断
__GENUS或结合Win32_BIOS.SerialNumber交叉验证
Linux下读取/sys/class/dmi/id/product_uuid
Linux依赖内核暴露的DMI信息，路径 /sys/class/dmi/id/product_uuid 是最直接来源，但权限和可用性有坑：普通用户默认无读取权限，且部分精简内核（如某些容器镜像、ChromeOS）会禁用DMI支持。
不能用 /proc/sys/kernel/random/uuid ——那是随机生成的软件UUID，和硬件无关；也不建议解析 dmidecode 输出，因为需要root权限且输出格式不稳定。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 打开文件前先检查是否存在且可读：
access("/sys/class/dmi/id/product_uuid", R_OK) == 0 - 读出内容末尾带换行符，需用
strcspn(buf, "\n")截断 - 值全为大写字母和短横（如
87C6F9A2-4E5D-4F7B-A123-456789ABCDEF），小写转换需手动处理 - 若失败，可降级尝试
/sys/class/dmi/id/chassis_id或/sys/class/dmi/id/board_serial，但唯一性和稳定性依次下降
macOS没有等效的硬件UUID，只能用IOPlatformUUID
macOS不提供传统PC意义上的硬件UUID，IOPlatformUUID 是最接近的替代项——它由固件生成，重启/重装系统不变，但重刷固件或某些维修操作可能重置。不能用 IOPlatformUUID 的变体如 IOPlatformUUIDString（不存在），也不能依赖 system_profiler 的文本输出（格式易变）。
必须通过I/O Kit API获取，绕不开 IOServiceGetMatchingServices 和 IORegistryEntryCreateCFProperty。
- 需链接
-framework IOKit -framework CoreFoundation - 匹配字典必须设为：
IOServiceMatching("IOPlatformExpertDevice")，其他类名（如 "IOACPIPlatformExpert"）可能返回空 - CFType返回的是
CFUUIDRef，要转成字符串用CFUUIDCreateString，再转C字符串需用CFStringGetCString并指定编码kCFStringEncodingUTF8 - 沙盒应用默认禁止访问该属性，需在entitlements中添加
com.apple.developer.kernel.extended-info（仅限特定场景，多数第三方应用无法启用）
跨平台封装要注意的三个硬约束
别幻想一个函数调所有平台都返回相同语义的UUID——Windows的WMI、Linux的DMI、macOS的IOKit三者来源不同、生成时机不同、重置条件不同。强行统一格式只会掩盖差异。
- 返回值类型建议用
std::optional<:string></:string>，而非默认空字符串，避免把“获取失败”误判为“有效空UUID” - 不要缓存结果：Windows WMI查询有开销但稳定；Linux DMI文件每次open/read即可，无需stat缓存；macOS每次调I/O Kit API开销可控
- 测试时务必在真实物理机上验证，VMware Fusion/Parallels Desktop对
IOPlatformUUID和product_uuid模拟行为不一致，QEMU甚至直接返回错误
真正难的不是调用API，而是理解每个平台“UUID”实际代表什么层级的实体——是主板？固件实例？还是整机抽象？选错源头，后面所有逻辑都会漂移。
