Windows下CPU序列号默认不可读取，因Intel自Pentium III起禁用、AMD未实现，且Win10/11主动屏蔽；WMI的SerialNumber多为空，ProcessorId仅为型号摘要（非唯一），不可用于可靠硬件绑定。
Windows 下的 CPU 序列号（CPUID）在现代 x86/x64 处理器中**默认不可读取**，且 .NET（包括 C#）没有提供直接获取“CPU 序列号”的安全、稳定、跨平台 API。所谓“读取 CPU 序列号”在绝大多数实际场景中是误传或混淆概念，真正能稳定获取的是 CPU ID（处理器型号标识符，非唯一序列）、ProcessorId（WMI 中的十六进制摘要值，非物理序列号），或需管理员权限+内核驱动配合的低级寄存器读取（已被 Windows 禁用或虚拟化拦截）。
为什么 Win32_Processor.SerialNumber 返回空或 "Not Available"
这是最常踩的坑：WMI 的 SerialNumber 属性在绝大多数消费级 CPU 上根本不会暴露真实序列号。Intel 自 Pentium III 后就默认禁用该功能；AMD 从未实现；Windows 10/11 更是主动屏蔽该字段以保护隐私和安全。
- 即使以管理员权限运行，
ManagementObjectSearcher("SELECT SerialNumber FROM Win32_Processor")返回的也几乎总是空字符串或"None" - 部分 OEM 笔记本（如某些 Dell/HP 机型）可能填充了 BIOS 设置的资产标签，但这与 CPU 无关，属于主板或固件层信息
- 该字段不具唯一性、不可靠，**不能用于授权或绑定硬件**
Win32_Processor.ProcessorId 是什么？能用吗？
ProcessorId 是 WMI 提供的一个 64 位十六进制值（如 "BFEBFBFF000806EA"），它本质是 cpuid 指令返回的 Signature + FeatureFlags 的组合摘要，反映 CPU 型号、步进、支持特性，**不是序列号，也不唯一**——同一型号、同批次的 CPU 会返回完全相同的 ProcessorId。
- 可用代码获取：
var mos = new ManagementObjectSearcher("SELECT ProcessorId FROM Win32_Processor"); foreach (ManagementObject mo in mos.Get()) { string pid = mo["ProcessorId"]?.ToString(); // 注意判空 } - 优点：无需管理员权限，稳定可读，适合粗粒度硬件分组
- 缺点：虚拟机中易重复（尤其 Hyper-V/VirtualBox 默认克隆 CPU 特性）；多 CPU 系统返回首个物理 CPU 的值；不能区分同型号不同个体
真正可用于软件授权的硬件指纹怎么构造？
单一硬件 ID 风险极高（换硬盘、重装系统、虚拟机迁移都会失效）。可靠做法是组合多个稳定、难伪造、用户不易察觉变更的标识，加权哈希：
- 必选：
VolumeSerialNumber（系统盘卷序列号，DriveInfo.GetDrives().First().VolumeSerialNumber）——重装系统会变，但用户感知低 - 推荐：
MachineGuid（注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid）——重装系统保留，重置 Windows 时才变 - 辅助：
MAC 地址（首块启用网卡）——注意隐私合规，需用户授权；VM 中可能动态生成 - 避免：
主板序列号（Win32_BaseBoard.SerialNumber，OEM 常为空）、BIOS SerialNumber（同上）、CPU Name（易被虚拟化欺骗） - 关键：所有值应统一转小写、去空格、按固定顺序拼接后做
SHA256哈希，而非明文存储或简单拼接
如果坚持要底层 CPU ID，有哪些现实限制？
调用 cpuid 指令本身是可行的（通过内联汇编或 P/Invoke 调用 kernel32.dll 的未公开接口），但：
- Windows 用户模式下无法直接执行
cpuid获取序列号（需要CR4.PCE=1和特权指令支持，普通进程无权访问） - 现代 CPU（Intel 之后的 Core 系列、AMD Ryzen）已彻底移除序列号功能，
cpuid的EAX=1或EAX=3不再返回有效序列字段 - 任何声称“纯 C# 无驱动读取 CPU 序列号”的库，要么返回伪造值，要么实际读取的是
ProcessorId或其他替代字段 - 企业级授权方案（如 Sentinel、FlexNet）早已弃用 CPU ID，转向绑定激活服务器 + 设备指纹 + 在线验证混合机制
真正棘手的不是“怎么读”，而是“读出来的东西是否在用户换 SSD、升级主板、开 Hyper-V 后还能保持一致”。多数失败的授权逻辑，都栽在把 ProcessorId 当成唯一 ID 用了——它只是 CPU 的“身份证号”，不是“身份证上的唯一编号”。
