不存在跨平台、系统级保证的唯一硬件UUID；所有方案均为权衡妥协，需调用系统API或读取底层信息，且多数依赖管理员权限。
没有跨平台、系统级保证的“唯一硬件 UUID”——所有方案都是权衡妥协，C++ 本身不提供该能力，必须调用系统 API 或读取底层信息，且多数场景下需管理员/root 权限。
为什么 GetVolumeInformation（Windows）或 /sys/class/dmi/id/product_uuid（Linux）不能直接当“硬件 UUID”用
这些接口返回的标识符常被误认为是“主板/设备唯一 ID”，但实际受制于固件实现和虚拟化环境：
-
product_uuid在多数物理机上来自 SMBIOS DMI 表，但很多 OEM 厂商填的是全零、重复值或占位符（如00000000-0000-0000-0000-000000000000） -
GetVolumeInformation返回的是卷序列号（volume serial number），绑定磁盘分区而非硬件，重装系统或格式化即变 - VMware/VirtualBox 等虚拟机默认生成随机 UUID，重启不变，但克隆后极易重复；Hyper-V 可配置为“基于主机硬件生成”，但需手动启用
- macOS 的
IOPlatformUUID相对可靠，但仅限 Apple 设备，且在 T2/M1+ 芯片上受安全策略限制（需 entitlements 和用户授权）
Linux 下读取 DMI + CPUID + MAC 的组合策略（需 root）
单一来源不可靠，可拼接多个字段并哈希，降低冲突概率。重点不是“绝对唯一”，而是“在可控部署环境中足够区分”：
- 优先读
/sys/class/dmi/id/product_uuid（若非全零且可读） - fallback 到
/sys/class/dmi/id/board_serial+/sys/class/dmi/id/chassis_serial（部分服务器有真实序列） - 补充
cpuid指令获取 CPU stepping/model/family（需内联汇编或__cpuid），但注意多 CPU 时需固定取 core 0 - 取第一个非 loopback、非 docker/veth 的 MAC 地址（
/sys/class/net/*/address），过滤掉00:00:00:00:00:00和 VMware/VirtualBox 厂商前缀（00:05:69,00:0c:29,00:1c:42） - 最终用 SHA-256 哈希拼接字符串（如
"uuid:xxx|board:yyy|mac:zzz"），输出 32 字节 hex
注意：/sys/class/dmi/id/ 下多数文件需 root 权限；无 root 时只能退到 /proc/cpuinfo（易被伪造）或 /etc/machine-id（绑定 OS 安装，非硬件）。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
Windows 上用 WMI 查询 Win32_ComputerSystemProduct 和 Win32_BIOS
比注册表或 volume serial 更接近硬件层，但仍要处理空值和虚拟机噪声：
- 查询
UUID字段（对应 SMBIOS Type 1）：用IWbemServices::ExecQuery执行SELECT UUID FROM Win32_ComputerSystemProduct - 若为空或无效（如
FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF），fallback 到IdentifyingNumber（主板序列号）或Win32_BIOS.SerialNumber - 避免用
Win32_NetworkAdapterConfiguration.MACAddress：它返回的是驱动上报值，可能被netsh interface set interface临时修改 - WMI 调用需初始化 COM（
CoInitializeEx）、设置安全上下文（CoSetProxyBlanket），否则在服务进程或无桌面会话中失败
示例关键判断逻辑：
if (uuid == L"00000000-0000-0000-0000-000000000000" ||
uuid.find(L"FFFF") == 0) {
// 回退到 BIOS SerialNumber
}
macOS 上通过 IOKit 获取 IOPlatformUUID（需适配签名与权限）
这是 Apple 官方推荐的“设备唯一性标识”，但自 macOS 10.15+ 受隐私管控：
- 必须在
Info.plist中声明com.apple.developer.device-identifierentitlement，且 App 需通过 Mac App Store 或开发者 ID 签名 - 运行时首次访问会触发系统弹窗请求用户授权（类似定位权限），拒绝后返回空字符串
- 代码需链接
IOKit.framework，用IOServiceGetMatchingServices查找IOPlatformExpertDevice，再用IORegistryEntryCreateCFProperty读取kIOPlatformUUIDKey - 模拟器（Xcode Run）下返回固定值（如
00000000-0000-0000-0000-000000000000），不可用于测试唯一性
没权限时唯一可行 fallback 是 gethostuuid()（已废弃）或生成并持久化本地 UUID 到 ~/Library/Application Support/ —— 但这属于软件级 ID，与硬件无关。
真正难的不是读哪个文件或调哪个 API，而是判断“当前环境是否可信”：物理机？什么品牌？是否云主机？有没有权限？要不要支持离线激活？这些决策点远比拼接字符串复杂得多。
