WMI 的 Win32_Processor.ProcessorId 在多数机器上不可靠，虚拟机为空、物理机常为固定CPU型号编码而非唯一序列，不能用于硬件唯一标识。
为什么 WMI 读出来的 CPU ID 在多数机器上是空的或重复的
Windows 不向普通应用暴露真实的 CPU 序列号（Intel/AMD 官方已禁用该功能），Win32_Processor 的 ProcessorId 字段在现代系统中基本不可靠：虚拟机返回空，物理机常为固定值（如 BFEBFBFF000906EA 这类 CPU 型号编码），不是唯一序列。直接查这个字段等于白忙。
实操建议：
- 别依赖
ProcessorId做授权或绑定——它不满足“硬件唯一”前提 - 若必须用 WMI，可组合
Win32_BIOS.SerialNumber+Win32_DiskDrive.SerialNumber+Win32_NetworkAdapter.MACAddress（过滤掉虚拟网卡）生成哈希，但需处理权限、空值、多磁盘等边界 - 注意：BIOS 序列号在部分 OEM 机器（如联想、戴尔出厂机）是空的或全零
ManagementObjectSearcher 查询时权限不足或抛出 UnauthorizedAccessException
WMI 查询需要调用方有足够权限，尤其访问 Win32_BIOS 或硬盘序列时，非管理员账户常失败；.NET Core/.NET 5+ 默认以低完整性级别运行，更容易被拦截。
实操建议：
- 开发阶段右键 VS → “以管理员身份运行”，避免权限报错干扰调试
- 生产环境不要硬性要求管理员权限，改用降级策略：先尝试 BIOS，失败则 fallback 到主板信息（
Win32_BaseBoard.SerialNumber），再 fallback 到卷序列号（GetVolumeInformation） - 捕获
UnauthorizedAccessException和ManagementException，不要让整个识别流程崩掉
用 GetVolumeInformation 获取磁盘卷标 vs 硬件序列的区别
GetVolumeInformation 返回的是 NTFS/FAT 卷的序列号（lpVolumeSerialNumber），属于文件系统层标识，重装系统、格式化后会变；它不是硬盘物理序列号（Win32_DiskDrive.SerialNumber），后者需管理员权限且部分 SSD 厂商不提供。
实操建议：
- 卷序列号适合短期设备绑定（如本地缓存校验），不适合长期授权——用户一键重装就失效
- 物理硬盘序列可用
Win32_DiskDrive查，但要排除 USB 移动硬盘（InterfaceType != "USB"）、NVMe 虚拟盘（PNPDeviceID含VEN_144D等需过滤） - 混合方案更稳：取系统盘卷序列 + 主板序列 + CPU 型号哈希，三者缺一补二
.NET 6+ 中用 System.Management 需手动引用且跨平台失效
System.Management 在 .NET Framework 下开箱即用，但在 .NET Core 5+ 中需显式安装 NuGet 包 System.Management，且仅支持 Windows；Linux/macOS 下直接报 PlatformNotSupportedException。
实操建议：
- 项目文件加：
<packagereference include="System.Management" version="8.0.0"></packagereference> - 写法要守卫平台：
#if WINDOWS包裹 WMI 逻辑，否则走Environment.MachineName+Guid.NewGuid()（仅作兜底） - 别在
Global.asax或 ASP.NET Core 中间件里无条件调 WMI——IIS 应用池默认没 WMI 权限，容易静默失败
实际做设备指纹，最常被忽略的是“同一台机器不同用户登录时，WMI 查询结果是否一致”。答案是：一致（WMI 是系统级），但如果你用了 Environment.GetFolderPath 这类用户路径参与计算，就引入了变量。硬件标识本身不难拿，难的是把各种空、权限、虚拟化、OEM 厂商阉割的情况都兜住。
