真正稳定获取硬盘序列号应弃用wmi的serialnumber字段，改用win32_diskdrive的model+index+非空serialnumber拼接或pnpdeviceid末段哈希；mac需过滤虚拟/无线网卡取首个有线网卡物理地址；机器码须固定字段顺序、空值标准化后统一sha256哈希生成base64字符串。
用 ManagementObjectSearcher 读硬盘序列号，但别信 WMI 返回的 SerialNumber 字段
Windows 下通过 WMI 获取硬盘序列号最常用，但实际拿到的 SerialNumber 往往是空、乱码或厂商虚拟值（尤其 NVMe SSD 和某些品牌笔记本），根本不能用于机器绑定。
真正稳定可用的是物理磁盘的 PNPDeviceID 或 InterfaceType + Manufacturer + Model 组合后哈希，再配合 Win32_DiskDrive 的 Index 做唯一性锚点：
- 优先查
Win32_DiskDrive，过滤掉InterfaceType == "USB"的移动盘 - 取第一个非 USB 磁盘的
Model+SerialNumber（若非空）+Index拼接后做 SHA256 - 如果
SerialNumber为空，用PNPDeviceID截取最后一段（通常是硬件 ID 哈希片段）替代 - 注意：
ManagementObjectSearcher需要管理员权限才能读部分字段，普通用户下可能抛UnauthorizedAccessException
获取 MAC 地址时，NetworkInterface.GetPhysicalAddress() 返回的是啥？
它返回的是网卡的物理 MAC，但问题在于——现代 Windows 默认启用“随机硬件地址”（尤其 Wi-Fi），每次连接网络都可能变；而且虚拟机、Docker、Hyper-V 虚拟网卡、蓝牙 PAN 接口也会返回额外 MAC，数量不定。
安全绑定必须过滤并锁定真实有线网卡：
- 遍历
NetworkInterface.GetAllNetworkInterfaces() - 只保留
OperationalStatus == OperationalStatus.Up且NetworkInterfaceType是Ethernet或GigabitEthernet的接口 - 排除名称含
"Virtual"、"Hyper-V"、"vEthernet"、"Bluetooth"的适配器（靠Description或Name判断） - 取第一个符合条件的 MAC，转成无分隔符大写字符串（如
"001A2B3C4D5E"），再参与哈希 - 别用
GetIPProperties().UnicastAddresses反推网卡——IPv6 临时地址或 DHCP 租约变化会导致关联错乱
组合机器码时，为什么不能直接拼接硬盘 + MAC 字符串？
因为单个硬件信息可能缺失或不稳定，拼接明文还容易被逆向篡改。机器码本质是“可重现、难伪造、跨重启一致”的指纹，不是原始数据展示。
推荐做法是构造确定性输入后统一哈希：
- 输入字段固定顺序：硬盘标识（处理后的）、主网卡 MAC、主板
Win32_BaseBoard的SerialNumber（若可读）、CPU ID（Win32_Processor的ProcessorId） - 每个字段先
.Trim()再转大写，空值统一替换为"N/A"，避免因 null 导致哈希不一致 - 用
SHA256.HashData()（.NET 5+）或SHA256.Create().ComputeHash()计算字节数组哈希，最后转 Base64 或十六进制字符串（建议 Base64，更短且无符号问题） - 不加盐——盐会破坏“可重现”；也不加密——没意义，客户端本就不可信
验证阶段发现机器码变了？先检查这三件事
授权失效不一定是算法错，大概率是运行环境或权限导致底层信息采集失败：
- 程序是否以管理员权限运行？WMI 查询硬盘和主板序列号在标准用户下常被拦截，静默返回空值
- 目标机器是否装了安全软件（如 360、火绒）？它们会 hook WMI 调用或屏蔽敏感字段，表现为
SerialNumber全是星号或空字符串 - 是否在虚拟机或云桌面（如 Citrix、Windows 365）中测试？这类环境往往禁用物理设备枚举，
Win32_DiskDrive可能只返回虚拟磁盘，ProcessorId恒为"0000-0000-0000-0000"
真正难处理的是双硬盘、NVMe 多盘、雷电扩展坞挂载等情况——没有银弹，得在采集逻辑里加 fallback：比如主盘失败就退到次盘，全盘不可用就用 CPU + 主板 + MAC 三元组，但务必记录降级原因供调试。
