最稳定方案是WMI查询Win32_ComputerSystemProduct.UUID，需初始化COM并设置代理安全上下文；若为空或全零，应fallback至MachineGuid，而非强行读取SMBIOS/ACPI。
Windows 下 C++ 获取硬件 UUID，优先走 WMI 查询 Win32_ComputerSystemProduct 的 UUID 属性；若需绕过 WMI（如服务被禁、权限受限），才考虑直接读取 ACPI DSDT 或 SMBIOS 表——但后者需驱动级权限或第三方库，普通应用几乎不可行。
WMI 查询 UUID 是最稳定、无需提权的方案
绝大多数场景下，Win32_ComputerSystemProduct.UUID 返回的就是 BIOS/UEFI 固件写入的机器唯一标识，和 Windows 激活、设备注册用的是同一个值。它不依赖磁盘或网络配置，重启、重装系统后保持不变。
- 必须初始化 COM：调用
CoInitializeEx(nullptr, COINIT_MULTITHREADED)，否则 WMI 调用直接失败 - 必须设置安全上下文：至少调用
CoSetProxyBlanket配置默认代理，否则本地 WMI 查询会返回0x80070005（拒绝访问） - 查询语句别写错：
"SELECT UUID FROM Win32_ComputerSystemProduct"，字段名大小写敏感，表名不能拼成ComputerSystemProduct或漏掉Win32_ - 结果为空？先手动用 PowerShell 验证：
Get-WmiObject Win32_ComputerSystemProduct | Select-Object UUID—— 若 PowerShell 也空，说明固件根本没写 UUID（常见于老旧主板或虚拟机）
WMI 查询失败时，不要硬刚 SMBIOS 或 ACPI
网上很多教程鼓吹用 GetSystemFirmwareTable 读取 SMBIOS Type 1 表、或解析 DSDT 中的 ECDID，这些在用户态 C++ 程序里基本走不通：
-
GetSystemFirmwareTable("RSMB", 1, ...)在多数 Windows 版本上返回 0，且需要SE_SYSTEM_ENVIRONMENT_NAME权限（即管理员+策略开启），普通安装包无法要求用户开这个策略 - 直接 mmap 物理内存或读取
\.PhysicalMemory在 Win10/11 上默认禁用，驱动签名强制启用，应用层无解 - 依赖
OpenHardwareMonitor或libcpuid等第三方库？它们底层仍靠 WMI 或已弃用接口，兼容性更差，还引入额外 DLL 依赖
UUID 字符串格式与截断风险要主动处理
WMI 返回的 UUID 是标准 36 字符格式（如 00000000-0000-0000-0000-000000000000），但某些 OEM 厂商填的是全零、或只填了前 8 位（如 12345678-0000-0000-0000-000000000000），甚至混入空格或不可见字符。
立即学习“C++免费学习笔记（深入）”；
- 务必用
std::wstring接收，避免 ANSI 转码丢失 - 调用
VariantChangeType转为VT_BSTR后，用wcscmp检查是否全零：if (all_of(uuid.begin(), uuid.end(), [](wchar_t c) { return c == L'0' || c == L'-'; })) - 不要直接拿 UUID 做加密密钥或数据库主键——先做有效性校验，无效时 fallback 到
GetMachineGuid（注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid）更实际
真正难的不是“怎么查”，而是判断查出来的值能不能信。固件层 UUID 缺失或造假太常见，业务逻辑里必须预设 fallback 路径，而不是卡死在“一定要硬件 UUID”这个执念上。
