WMI中Win32_Processor的ProcessorId并非CPU序列号，而是厂商编码，同一型号CPU值相同；Intel/AMD早已默认禁用真实序列号，BIOS中通常不可启用；安全场景应采用多硬件信息哈希（如UUID+磁盘SN+MAC）而非单点ID。
Windows下用WMI读取CPUID不等于序列号
很多人以为调用 Win32_Processor 的 ProcessorId 属性就能拿到“CPU序列号”，实际不是。这个值是CPU厂商编码（如Intel的BFEBFBFF000806EA），由型号、步进、缓存等拼成，同一型号所有CPU完全一致，且在虚拟机里常为占位符（如全0或重复值）。它不可用于唯一设备识别，更不满足安全场景要求。
真正意义上的CPU序列号（SerialNumber）自2000年代初起，Intel和AMD已**默认禁用**——出于隐私与安全考虑，BIOS/UEFI固件层面就不再暴露该字段。即使主板支持，也需手动在BIOS中开启“Processor Serial Number”选项（现代主板基本已移除此选项）。
所以：你无法通过标准WMI或内核API稳定、跨平台、合规地获取真实CPU序列号。
替代方案：组合硬件哈希比单点ID更可靠
安全场景下，硬要一个“设备指纹”，应放弃依赖单一硬件字段，改用多源信息哈希。常见组合包括：
立即学习“C++免费学习笔记（深入）”；
-
Win32_ComputerSystemProduct的UUID（主板级，虚拟机中可能重复或随机） -
Win32_DiskDrive的SerialNumber（需管理员权限，部分NVMe盘返回空） -
Win32_NetworkAdapter中启用的网卡的MACAddress（可被伪造，但结合其他字段仍有效） -
Win32_VideoController的Name+VideoProcessor（辅助防虚拟机）
示例哈希逻辑（C++伪代码）：
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
std::string hw_id = uuid + "|" + disk_sn + "|" + mac; std::string fingerprint = sha256(hw_id); // 非加密用途可用MD5，但别用于授权校验
注意：disk_sn 在Windows 10+需启用 SeBackupPrivilege 权限才能读取；MACAddress 在WiFi断开时可能为空；UUID 在Hyper-V等虚拟化环境中常为00000000-0000-0000-0000-000000000000。
Linux下/dev/cpu/*/cpuid不可读取序列号
Linux用户常查 /dev/cpu/0/cpuid 或用 cpuid 指令，但它只返回CPU功能位图（feature flags）、厂商字符串、基础频率等，不包含序列号字段。执行 cpuid -r 0x00000001 得到的是EAX（stepping/model/family）、EBX（brand index等），没有序列相关寄存器输出。
Linux下唯一接近的路径是读取DMI数据：sudo dmidecode -t processor | grep "ID:"，但该ID仍是处理器标识符（类似WMI的ProcessorId），非序列号；且需要root权限，容器中通常不可用。
安全红线：别把硬件ID当密钥或长期凭证
任何硬件标识都可能变化：换硬盘、重装系统、启停虚拟机、更新BIOS、甚至某些USB-C扩展坞插入都会触发MAC地址重生成。若用于软件授权，必须配合服务端绑定+宽松漂移策略（例如允许3个字段中2个匹配即视为同一设备）。
更关键的是：在沙箱、CI环境、Docker容器中，这些WMI或DMI接口大概率返回空、默认值或报错（如WBEM_E_ACCESS_DENIED）。强行依赖会导致初始化失败或误判设备变更。
真要高安全性设备绑定，应走TPM 2.0的TPM2_CreatePrimary + 密封密钥路径，而非拼接字符串哈希。
