前阵子帮一个小团队收尾设备授权模块，需求本身很朴素：程序要同时跑在 Windows 和 Linux 上，采集到机器的 Mac 地址和 CPU 序列号，拼成一个稳定的机器码去绑定授权。结果他们上线第一周就出事了——同一台装了双系统的笔记本，Windows 那边算出来的机器码和 Linux 那边完全对不上，负责这事的同学一脸茫然，因为他取的是 WMI 里的 ProcessorId，以为那就是 CPU 出厂序列号，其实那串东西全世界同型号同步进的 CPU 都一样。类似这种误解，在我接触过的项目里出现频率高得离谱，Mac 地址怎么取、CPU 序列号到底存不存在、虚拟机上取到的值能不能当基准，这几个问题几乎每个做客户端的人都得撞上一次。
把 Mac 地址和 CPU 序列号在 Windows 和 Linux 上各实现一遍，代码量其实不大，加起来几百行，但里面藏着大量平台差异和语义陷阱。这篇就把这些年踩过的坑和最终稳定的实现方案整理出来，从 API 选型一路讲到跨平台封装和排查手段，Windows 和 Linux 两端都会给可直接编译的代码。不管你是在写授权模块、做资产盘点工具，还是单纯想搞清楚"000C29 开头的 Mac 地址是不是虚拟机"，都能直接拿去参考。
1. 先划清能力边界：哪些标识符真能用，哪些是幻觉
1.1 Mac 地址、ProcessorId、机器 UUID 的真实含义
很多人对这三个东西的理解是模糊的，先把定义说清楚。
Mac 地址是网卡上的 6 字节标识，前 3 字节叫 OUI，由 IEEE 分配给厂商，后 3 字节由厂商自己分配。它"全球唯一"这个说法有两个前提：一是厂商老老实实按分配结果烧写，二是没人去改它。现实中这两个前提都靠不住。网卡驱动允许软件层覆盖 Mac 地址，Windows 上在网卡属性里填一个"网络地址"就能生效，Linux 上一条ip link set dev eth0 address xx:xx:xx:xx:xx:xx也是瞬间完成。虚拟化平台更是自己造地址，同一台虚拟机重新克隆一次，Mac 就换了一个。
CPU 序列号这块误会最深。x86 平台上，CPUID 指令有一组功能叶子，其中EAX=1返回的是处理器版本信息、特性标志位这些内容，Windows 的 WMI 把其中 EDX 和 EAX 拼起来做成Win32_Processor.ProcessorId。它描述的是"这颗 CPU 是什么型号、什么步进、支持哪些指令集"，不是"这一颗 CPU 的身份证"。同一条产线上出来的一万颗 i7，这个值完全相同。Intel 早期确实在 Pentium III 上提供过CPUID EAX=3返回的处理器序列号，但因为隐私争议，后续产品里这个功能被去掉了，现代 x86 拿不到真正唯一的 CPU 序列号。
ARM 平台反而是另一回事。树莓派这类板子在/proc/cpuinfo里会有一个Serial字段，来自芯片内部的一次性可编程存储区，是真正唯一的。所以你在 ARM 板上写的采集代码和在 x86 服务器上写的，逻辑完全不同，这点后面第三章会展开。
机器 UUID 是这三者里最接近"设备唯一标识"的东西。它来自主板固件里的 SMBIOS Type 1 表，由主板厂商在出厂时写入，Windows 上用wmic csproduct get uuid或Get-CimInstance Win32_ComputerSystemProduct能读到，Linux 上对应/sys/class/dmi/id/product_uuid。但它也有软肋：虚拟机克隆时如果选择保留原始 UUID，新机器和老机器会撞号；批量部署的系统镜像如果没有重新生成，也会出现重复。
| 标识符 | 典型来源 | 唯一性 | 是否容易被改 | 采集难度 |
|---|---|---|---|---|
| Mac 地址 | 网卡固件 / 虚拟化平台分配 | 中等 | 容易，软件层即可覆盖 | 低 |
| CPU ProcessorId | CPUID 指令 EAX=1 | 低，同型号完全一致 | 不可改 | 低 |
| 机器 UUID | SMBIOS Type 1 | 高 | 克隆、刷固件会变 | Windows 低，Linux 需权限 |
| machine-id | 系统安装时生成 | 高 | 镜像克隆会重复 | 低 |
1.2 为什么设备指纹最后都变成多因子组合
单因子方案的失败案例我见得太多了。用 Mac 地址做唯一键，用户插了一个 USB 网卡、或者笔记本从有线切到无线，机器码就变了，授权直接失效。用 ProcessorId 做唯一键，两台同型号的办公电脑直接互相顶掉授权。用机器 UUID 做唯一键，IT 部门用同一份镜像批量装机，一百台机器共用一个授权。
比较靠谱的做法是采一组因子，按稳定性和唯一性排优先级，允许部分缺失，最后归一化成一个固定长度的摘要。具体来说：机器 UUID 权重最高，但它在 Linux 上需要 root 权限才能读到，普通用户进程拿不到，所以不能作为唯一依赖；Mac 地址取物理网卡的那一块，权重次之，允许采集不到（比如只有无线网卡且处于关闭状态）；ProcessorId 和 CPU 型号信息作为辅助因子加入哈希，它虽然不唯一，但能区分不同批次、不同型号的机器，对降低碰撞率有帮助。
采集设备标识用于授权或资产场景时，只采集设备侧的硬件信息就够了，别顺手把主机名、用户名、IP 一起塞进哈希，这些属于会变的信息，会让指纹的稳定性大打折扣。
哈希之前的归一化也很关键。Windows 上 WMI 返回的 Mac 是大写带冒号的格式，Linux 的 sysfs 返回的是小写带冒号，ARM 板子上有些接口返回不带分隔符的纯十六进制。这些格式差异必须在拼字符串之前统一处理，否则同一台机器在两个系统上算出来的摘要天然不同。我在实现里统一转成小写、去冒号、去空格的 12 位十六进制串，再进行拼接。
2. Windows 端：原生 API 和 WMI 各有一套打法
2.1 用 GetAdaptersAddresses 取 Mac 地址的完整写法
Windows 上取 Mac 地址有至少四条路：GetAdaptersInfo、GetAdaptersAddresses、WMI 查询、读注册表。GetAdaptersInfo是老接口，网卡数量多的时候缓冲区不够用，而且对 IPv6 支持不好，基本可以淘汰。读注册表需要自己处理NetworkAddress覆盖的情况，容易漏掉虚拟网卡。WMI 查询简单但要初始化 COM，开销大。综合下来，GetAdaptersAddresses是首选，它在 IP Helper API 里，能一次拿到网卡类型、运行状态、物理地址长度这些关键属性。
这个 API 有个必须处理的调用约定：第一次调用时如果缓冲区不够，它返回ERROR_BUFFER_OVERFLOW，同时把需要的长度写回size参数，你得重新分配再调一次。很多示例代码直接写死 15KB 缓冲区，在网卡特别多的服务器上（虚拟化环境下一台机器挂几十块虚拟网卡很常见）会直接失败。正确做法是循环重试，我一般写三次上限。
过滤逻辑是这里的核心价值所在。单纯遍历列表返回第一块网卡，大概率会拿到一个虚拟适配器或者已经断开的连接。要按这几个条件筛：
IfType必须是IF_TYPE_ETHERNET_CSMACD（6，有线）或IF_TYPE_IEEE80211（71，无线），这样能过滤掉回环、隧道、蓝牙 PAN 这些非物理网卡；OperStatus必须是IfOperStatusUp，避免拿到一块插着网线但没连通、或者无线没连上的网卡；PhysicalAddressLength必须是 6，有些适配器（比如某些 InfiniBand 设备）返回 20 字节，直接按 6 字节格式化会读到越界数据。
还有一个坑是头文件顺序。winsock2.h必须在windows.h之前包含，否则老版本的winsock.h会被windows.h带进来，两套定义冲突，编译期就是一堆重定义错误。这个坑从 VC6 时代延续到现在，每年都有人栽。
2.2 WMI 查询 ProcessorId：先搞明白它返回的是什么
前面说过Win32_Processor.ProcessorId不是唯一序列号，那为什么还要用它？因为它是跨平台对齐的一个基准点。你在 Windows 上用 CPUID 指令自己算出来的值，应该和 WMI 返回的一致，这样两边的实现可以互相校验，出了偏差一眼就能看出来。
WMI 那条路本身也有几个必须掌握的点。第一是 COM 初始化，CoInitializeEx传COINIT_MULTITHREADED表示多线程模型，但如果宿主进程已经在单线程模型（STA）里初始化过 COM，这次调用会返回RPC_E_CHANGED_MODE。很多示例代码一看到这个错误就直接 return false 放弃采集，其实这时候 COM 环境是可用的，只要不再调用CoUninitialize就行。这是很典型的一个判断错误。
第二是CoSetProxyBlanket。WMI 的ExecQuery调用如果没设置代理安全级别，会返回0x80070005拒绝访问，而且这个错误在有管理员权限时和没有权限时表现一样，很难排查。必须对从ConnectServer拿到的IWbemServices接口调用一次CoSetProxyBlanket，把认证级别设成RPC_C_AUTHN_LEVEL_CALL，模拟级别设成RPC_C_IMP_LEVEL_IMPERSONATE。
第三是 VARIANT 和 BSTR 的释放。WMI 取回来的字符串是VT_BSTR类型，用完之后必须VariantClear，IWbemClassObject、IEnumWbemClassObject、IWbemServices、IWbemLocator每一层都要 Release。这些东西在循环里漏掉一个，程序跑几天内存就上去了。我见过一个资产采集客户端，因为漏了pEnum->Release()，跑一周占了两个 G。
| 调用步骤 | 关键接口 | 常见错误码 | 处理方式 |
|---|---|---|---|
| COM 初始化 | CoInitializeEx | RPC_E_CHANGED_MODE | 视为成功，不再反初始化 |
| 连接命名空间 | ConnectServer | 0x8004100E | 检查 ROOT\CIMV2 拼写 |
| 设置代理安全 | CoSetProxyBlanket | 0x80070005 | 必须调用，否则拒绝访问 |
| 执行查询 | ExecQuery | 0x80041017 | WQL 语法错误，通常是类名写错 |
2.3 一份可直接编译的 Windows 实现
把上面的要点落成代码。这份实现把 Mac 采集和 CPU 标识采集分开，方便按需调用，文件名建议叫hwid_win.cpp。
// hwid_win.cpp #define WIN32_LEAN_AND_MEAN #include <winsock2.h> // 必须排在 windows.h 之前 #include <windows.h> #include <iphlpapi.h> #include <intrin.h> #include <comdef.h> #include <Wbemidl.h> #include <cstdio> #include <string> #include <vector> #pragma comment(lib, "iphlpapi.lib") #pragma comment(lib, "ws2_32.lib") #pragma comment(lib, "wbemuuid.lib") #pragma comment(lib, "ole32.lib") #pragma comment(lib, "oleaut32.lib") // 取第一块处于连接状态的物理网卡 Mac，统一输出小写无分隔符 bool GetPrimaryMac(std::string& mac) { ULONG bufLen = 16 * 1024; std::vector<BYTE> buf; PIP_ADAPTER_ADDRESSES pAddrs = nullptr; ULONG ret = ERROR_BUFFER_OVERFLOW; for (int i = 0; i < 3; ++i) { buf.resize(bufLen); pAddrs = reinterpret_cast<PIP_ADAPTER_ADDRESSES>(buf.data()); ret = GetAdaptersAddresses( AF_UNSPEC, GAA_FLAG_SKIP_ANYCAST | GAA_FLAG_SKIP_MULTICAST | GAA_FLAG_SKIP_DNS_SERVER | GAA_FLAG_INCLUDE_PREFIX, nullptr, pAddrs, &bufLen); if (ret != ERROR_BUFFER_OVERFLOW) break; } if (ret != NO_ERROR) return false; for (PIP_ADAPTER_ADDRESSES p = pAddrs; p != nullptr; p = p->Next) { if (p->IfType != IF_TYPE_ETHERNET_CSMACD && p->IfType != IF_TYPE_IEEE80211) continue; if (p->OperStatus != IfOperStatusUp) continue; if (p->PhysicalAddressLength != 6) continue; char tmp[13] = {0}; snprintf(tmp, sizeof(tmp), "%02x%02x%02x%02x%02x%02x", p->PhysicalAddress[0], p->PhysicalAddress[1], p->PhysicalAddress[2], p->PhysicalAddress[3], p->PhysicalAddress[4], p->PhysicalAddress[5]); mac = tmp; return true; } return false; } // 用 CPUID 指令算出与 WMI 一致格式的 ProcessorId std::string GetProcessorId() { int regs[4] = {0}; __cpuid(regs, 1); // regs[0]=EAX regs[1]=EBX regs[2]=ECX regs[3]=EDX char buf[17] = {0}; snprintf(buf, sizeof(buf), "%08X%08X", static_cast<unsigned int>(regs[3]), static_cast<unsigned int>(regs[0])); return buf; } // 通用 WMI 单值查询 bool QueryWmi(const wchar_t* wql, const wchar_t* prop, std::wstring& result) { result.clear(); IWbemLocator* pLoc = nullptr; IWbemServices* pSvc = nullptr; IEnumWbemClassObject* pEnum = nullptr; bool ok = false; HRESULT hr = CoInitializeEx(nullptr, COINIT_MULTITHREADED); bool needUninit = SUCCEEDED(hr); if (FAILED(hr) && hr != RPC_E_CHANGED_MODE) return false; hr = CoCreateInstance(CLSID_WbemLocator, nullptr, CLSCTX_INPROC_SERVER, IID_IWbemLocator, reinterpret_cast<LPVOID*>(&pLoc)); if (FAILED(hr)) goto cleanup; hr = pLoc->ConnectServer(_bstr_t(L"ROOT\\CIMV2"), nullptr, nullptr, nullptr, 0, nullptr, nullptr, &pSvc); if (FAILED(hr)) goto cleanup; // 这一步漏掉就是 0x80070005 hr = CoSetProxyBlanket(pSvc, RPC_C_AUTHN_WINNT, RPC_C_AUTHZ_NONE, nullptr, RPC_C_AUTHN_LEVEL_CALL, RPC_C_IMP_LEVEL_IMPERSONATE, nullptr, EOAC_NONE); if (FAILED(hr)) goto cleanup; hr = pSvc->ExecQuery(_bstr_t(L"WQL"), _bstr_t(wql), WBEM_FLAG_FORWARD_ONLY | WBEM_FLAG_RETURN_IMMEDIATELY, nullptr, &pEnum); if (SUCCEEDED(hr)) { IWbemClassObject* pObj = nullptr; ULONG count = 0; if (pEnum->Next(WBEM_INFINITE, 1, &pObj, &count) == S_OK && count == 1) { VARIANT vt; VariantInit(&vt); if (SUCCEEDED(pObj->Get(prop, 0, &vt, nullptr, nullptr)) && vt.vt == VT_BSTR && vt.bstrVal != nullptr) { result.assign(vt.bstrVal, SysStringLen(vt.bstrVal)); ok = true; } VariantClear(&vt); pObj->Release(); } } cleanup: if (pEnum) pEnum->Release(); if (pSvc) pSvc->Release(); if (pLoc) pLoc->Release(); if (needUninit) CoUninitialize(); return ok; }编译命令用 MSVC 的话就一行：cl /EHsc /std:c++17 hwid_win.cpp。如果工具链老到没有snprintf（VS2015 之前），把它换成_snprintf_s(buf, sizeof(buf), _TRUNCATE, ...)即可，注意后者的参数顺序不一样。
GetProcessorId返回的前 8 位是 EDX，后 8 位是 EAX，这个顺序要和 WMI 的输出对齐，不然校验时会发现差了几位，白白折腾半天。拿不准就先在目标机器上跑一次wmic cpu get ProcessorId比对。
3. Linux 端：sysfs、ioctl 和 CPUID 三条路
3.1 取 Mac 地址的三种方式及各自适用场景
Linux 上取 Mac 地址最常见的是读/sys/class/net/<接口名>/address，一行文本，干净利落。这个文件是内核暴露的 sysfs 接口，读取不需要任何权限，容器里也能用（前提是容器网络命名空间里能看到那块网卡）。缺点是它只告诉你怎么读，不告诉你读哪一块——接口名从eth0到enp3s0到eno1，各发行版和 systemd 的命名策略都不一样，硬编码接口名的代码换一台机器就废了。
第二种是ioctl配合SIOCGIFHWADDR，这是比较传统的做法。开一个AF_INET的 socket，填好ifreq结构体里的接口名，调用 ioctl，从ifr_hwaddr.sa_data里取 6 字节。它的好处是能拿到内核记录的原始硬件地址，在某些被改写过地址的场景下更有参考价值。缺点是需要创建 socket，在 seccomp 沙箱比较严格的环境里（比如某些容器运行时默认策略）socket()调用可能被拦截返回EPERM，这时候整个采集就断了。
第三种是getifaddrs，一次拿到所有接口的地址列表，适合需要遍历全部网卡的场景。它返回的是sockaddr链表，需要判断sa_family是不是AF_PACKET，判断起来比读 sysfs 麻烦一点，但省去了自己开目录遍历的代码。
我的做法是主用 sysfs、ioctl兜底。枚举接口名时读/sys/class/net目录，因为这两个接口的语义完全一致，切换成本很低。这个组合在物理机、虚拟机、容器里都跑通过，是目前最稳的方案。
枚举时的过滤条件和 Windows 那边思路一致，但判断手段不同。/sys/class/net/<接口>/type文件里是 ARPHRD 类型码，以太网是 1，回环是 772，这个数字可以用来排除lo。至于区分物理网卡和虚拟网卡，有个很好用的小技巧：看/sys/class/net/<接口>/device这个软链接是否存在。真实的 PCI 或 USB 网卡会在 sysfs 里挂上对应的设备节点，而 veth pair、网桥、bond、tun/tap 这些纯软件接口没有对应的 device 节点。这个判据在绝大多数场景下都成立，比看接口名靠不靠谱得多。
排序也别忘了。目录遍历的顺序是不确定的，同一台机器两次运行可能返回不同的接口顺序，导致采集结果抖动。我一般在筛完之后对接口名做一次字典序排序，取第一个，保证结果稳定可复现。
3.2 x86 用 CPUID、ARM 读 cpuinfo，别搞反了
CPU 标识在 Linux 上的处理必须分架构。
x86 和 x86_64 上用 CPUID 指令，GCC 提供了<cpuid.h>这个头文件，里面封装了__get_cpuid函数，不用自己写内联汇编。调用__get_cpuid(1, &eax, &ebx, &ecx, &edx)就能拿到和 Windows 那边一致的数据。同样按 EDX 在前、EAX 在后的顺序拼成 16 位十六进制字符串，这样跨平台对比时能直接比对。
ARM 和 AArch64 没有 CPUID 这个东西，得去/proc/cpuinfo里翻。树莓派、很多国产嵌入式板子会在这里输出一个Serial字段，值来自芯片的一次性可编程区，是真正唯一的。但要注意，不是所有 ARM 板子都有这个字段，有些厂商出于隐私考虑把它去掉了，有些则换成了别的字段名。代码里必须做兼容，读不到就返回空字符串，让上层逻辑去处理。
这个差异还能延伸出一个很有意思的实践：不少嵌入式方案会把芯片的 96 位唯一 ID 通过哈希截断，生成一个本地管理地址格式的 Mac 地址烧到网卡上。这样做出来的地址前 3 字节的第二个 bit 是 1，属于本地管理地址段，一眼就能看出来不是 IEEE 分配的正规 OUI。做资产盘点的时候，看到这种地址就该知道这是设备自己造的，不能拿它去 OUI 库查厂商。
还有一个辅助手段是读 SMBIOS 数据。Linux 上/sys/class/dmi/id/product_uuid给出了机器 UUID，内容和 Windows 的Win32_ComputerSystemProduct.UUID是同一个东西，跨平台对齐非常好用。但它的读取权限是 0400，属于 root，普通用户进程打开会直接EACCES。所以设计上必须做好降级：读不到 product_uuid，就退到/etc/machine-id。
| 平台 | 首选方式 | 备用方式 | 是否需要 root |
|---|---|---|---|
| x86 / x86_64 | __get_cpuid(1,...) | 无 | 否 |
| ARM / AArch64 | /proc/cpuinfo的 Serial | 芯片唯一 ID 派生 | 否 |
| 通用机器标识 | /sys/class/dmi/id/product_uuid | /etc/machine-id | product_uuid 需要 |
3.3 容器、云主机和权限带来的坑
容器环境下有一堆特殊情况需要提前想清楚。
容器有独立的网络命名空间，/sys/class/net/eth0/address读到的是容器自己那块 veth 网卡的地址。这个地址在容器重建之后通常就变了，用它做机器指纹毫无意义。而且从容器里看，/sys/class/net/eth0/device这个软链接基本不存在，按 3.1 节的过滤规则会被直接筛掉，结果是采集不到任何网卡。这是合理的——容器本来就不该拿宿主机的物理地址。如果业务真需要，得通过挂载宿主机 sysfs 或者读取宿主机的 machine-id 来实现。
云主机的情况又不一样。主流云平台的实例里，SMBIOS 表和 CPUID 数据都是由虚拟化层构造的，可能被完全屏蔽，dmidecode -s system-uuid返回一长串 F 或者干脆报错。这时候/etc/machine-id是最可靠的兜底，它在系统首次启动时由 systemd 生成，重启不变，同镜像的不同实例不同（除非镜像是克隆出来的）。
权限问题是另一大块。除了 product_uuid 需要 root，dmidecode这个命令本身也需要 root，容器里通常还不允许访问/dev/mem，直接报错。所以线上采集程序最好用"能读就读，读不到就跳过"的策略，把权限不足当成一种正常情况处理，而不是抛异常中断流程。我见过一个采集脚本因为 product_uuid 读取失败直接退出，导致整个巡检任务失败，其实完全没必要。
容器里还有个容易忽略的点：如果容器用了 host 网络模式，
/sys/class/net里会看到宿主机的所有网卡，这时候采集到的就是宿主机地址。这个行为差异必须在文档里写清楚，否则同一份代码在不同部署方式下产出完全不同的指纹。
4. 从 Mac 地址前缀判断虚拟化：000C29 到底说明了什么
4.1 OUI 前缀对照表和本地管理地址位
"000C29 开头的 Mac 地址都是虚拟机吗"这个问题被问得很多，答案是基本可以这么判断，但推理过程值得说清楚。
00:0C:29这个 OUI 是分配给 VMware 的，专门用于它的虚拟网卡设备。VMware 旗下还有00:05:69、00:1C:14、00:50:56这几个前缀。这些地址在物理网卡上不会出现，所以你看到 000C29 开头，几乎可以断定这块网卡的宿主环境是 VMware 的虚拟化产品。
严格来说，OUI 只证明这个地址是由 IEEE 分配给该厂商的号段里来的，不能从协议层面强制证明"这是虚拟机"。但因为 VMware 不会把它分配出去的地址用在物理网卡上，实践中的判断是成立的。要说例外，只有人为伪造地址的情况——那已经不属于正常的硬件识别范畴了。
其他常见虚拟化平台的前缀我也整理了一下，做资产盘点的时候可以直接对照：
| OUI 前缀 | 平台 |
|---|---|
| 00:05:69 / 00:0C:29 / 00:1C:14 / 00:50:56 | VMware 系列 |
| 08:00:27 | VirtualBox |
| 00:15:5D | Hyper-V |
| 00:16:3E | Xen |
| 52:54:00 | QEMU / KVM 默认分配 |
比前缀判断更通用的一招，是看地址的第一个字节的本地管理位。Mac 地址第一个字节的最低位（bit 0）是单播/组播标志，次低位（bit 1）是"全球唯一"和"本地管理"的分界：这一位是 0，表示地址来自厂商分配的全球唯一号段；是 1，表示这是一个本地管理的地址，通常由软件生成或被人为改写。拿52:54:00举例，0x52 的二进制是0101 0010，从右往左数第二位是 1，所以它天然就是本地管理地址。QEMU 特意选这个号段，就是为了不占用正规的全球唯一地址空间。
这个知识点的实用价值在于：拿到一个地址，先看它是不是本地管理地址，如果是，基本可以判断它是由软件生成的，把它当作硬件标识来用风险很高。
4.2 用 DMI 信息做二次交叉验证
只靠 Mac 前缀判断虚拟化，遇到伪造地址的场景就失灵了。更稳的做法是拿 SMBIOS 信息做交叉验证。
Linux 上读这几个文件就够：/sys/class/dmi/id/sys_vendor、/sys/class/dmi/id/product_name、/sys/class/dmi/id/product_uuid。VMware 虚拟机的sys_vendor是VMware, Inc.，product_name是VMware Virtual Platform；VirtualBox 的product_name是VirtualBox；KVM 通常是Standard PC (i440FX + PIIX, 1996)或者厂商自定义的字符串。还有一个更省事的命令是systemd-detect-virt，它把各种判据都封装好了，输出vmware、kvm、docker这类短标识，直接给判断结果。
Windows 这边用一行 PowerShell 就能拿到对应信息：
Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer, Model Get-CimInstance Win32_BIOS | Select-Object SerialNumber, SMBIOSBIOSVersionVMware 虚拟机的 Manufacturer 是VMware, Inc.，Model 是VMware Virtual Platform。把这几个字段和 Mac 前缀一起看，基本不会误判。
还有一个实战经验：虚拟交换机对 Mac 的处理策略会影响你看到的结果。有些虚拟化平台默认开启了 Mac 地址更改和伪传输的相关策略控制，虚拟机发送源地址和配置不一致的帧会被丢弃，而采集程序如果是在虚拟机内部跑，读到的永远是配置值，不会感知到外层的策略。所以采集程序读到什么就是什么，别指望它能反映链路上的真实情况。
如果做的是网络侧资产盘点，还需要从交换机或路由器侧看接口的 Mac 表，比如display mac-address这类命令输出的结果，和主机侧自报的地址对照着看，才能发现地址伪装的情况。这是另一个层面的活了，和本文的主题不是一回事，但做资产盘点的人迟早会碰到。
5. 跨平台封装：一套接口、两种实现
5.1 数据结构与接口设计
两端的实现都跑通之后，下一步是把它们收进同一个接口里，让上层业务代码不用关心平台差异。这个抽象层不需要设计得很复杂，一个结构体加一个函数足够。
// hwid.h #pragma once #include <string> struct MachineInfo { std::string mac; // 小写、无分隔符的 12 位十六进制，可能为空 std::string cpu_id; // x86 为 16 位十六进制，ARM 为芯片序列号，可能为空 std::string machine_uuid; // SMBIOS UUID 或 machine-id，可能为空 int error_code; // 0 表示全部成功，非 0 表示部分或全部失败 }; // 返回采集到的信息，函数本身不抛异常 MachineInfo CollectMachineInfo(); // 把采集结果归一化成一个稳定的摘要，供授权或指纹使用 std::string BuildFingerprint(const MachineInfo& info);设计上有几个取舍值得说明。第一，每个字段都允许为空，而不是用异常或者失败返回来表示部分采集失败。硬件采集这种事，环境千奇百怪，能拿到什么算什么才是常态，强行要求全部成功只会让代码到处是 try-catch。第二，错误码只用来给日志和运维看，不参与业务判断，业务侧只看哪个字段为空就行。第三，BuildFingerprint单独抽出来，是为了让归一化和哈希的逻辑只写一遍，两端共用，避免出现"Windows 用大写、Linux 用小写"这种低级但致命的偏差。
摘要的生成逻辑我建议用 SHA-256，把三个字段按固定顺序拼起来做哈希，只要有一个字段非空就生成一个值：
std::string BuildFingerprint(const MachineInfo& info) { std::string raw; raw += "MAC=" + info.mac + "|"; raw += "CPU=" + info.cpu_id + "|"; raw += "UUID=" + info.machine_uuid + "|"; return Sha256Hex(raw); // 自行实现或引入一个轻量哈希库 }这里有个容易忽略的点：字段之间要加分隔符，而且分隔符不能出现在字段内容里。不加分隔符的话，mac="a"、uuid="bc"和mac="ab"、uuid="c"会算出同一个结果，虽然实际中不太可能发生，但这是个标准做法。
5.2 采集顺序、降级策略与错误码
采集顺序按"最稳定到最不稳定"排。机器 UUID 放第一位，它最不容易变；Mac 地址第二位；CPU 标识第三位。这样即使后面的采集全部失败，前面的结果也是可用的，业务侧可以按字段的可用性决定用哪几个做指纹。
降级策略要写死，不能临时判断。Linux 上的降级链路我设成三级：product_uuid→/etc/machine-id→/var/lib/dbus/machine-id。前两个都读不到的情况很少见，但确实遇到过（裁剪过的嵌入式系统里连 systemd 都没有），加上第三级基本就覆盖全了。Windows 上则是Win32_ComputerSystemProduct.UUID→ 注册表HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid，后者的读取不需要 COM，用RegGetValueW几行就能搞定，比 WMI 快得多。
性能上也值得考虑一下。WMI 查询的开销不小，一次ConnectServer加ExecQuery在慢一点的机器上要几百毫秒。如果采集逻辑在程序启动路径上，这个延迟是能感知的。我的做法是把 WMI 查询结果缓存起来，只在进程启动时采一次，后续复用；同时提供一个异步采集的接口，让主流程不被阻塞。
错误码的定义简单分几档就够了：0 表示全部成功，1 表示 Mac 采集失败，2 表示 CPU 标识采集失败，4 表示机器 UUID 采集失败，用位或的方式组合。这样一看错误码就知道是哪个环节的问题，比一个笼统的-1有用得多。
5.3 CMake 构建脚本与编译注意事项
跨平台项目用 CMake 管理最省事。关键是别把两个平台的源文件都编进去，否则在 Linux 上会遇到一堆 Windows 头文件的报错。
cmake_minimum_required(VERSION 3.15) project(hwid_demo CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(hwid_demo main.cpp) if(WIN32) target_sources(hwid_demo PRIVATE hwid_win.cpp) target_link_libraries(hwid_demo PRIVATE iphlpapi ws2_32 wbemuuid ole32 oleaut32) # 关闭一些会干扰 win32 API 的宏 target_compile_definitions(hwid_demo PRIVATE WIN32_LEAN_AND_MEAN NOMINMAX) else() target_sources(hwid_demo PRIVATE hwid_linux.cpp) target_link_libraries(hwid_demo PRIVATE pthread) endif()NOMINMAX这个宏在 Windows 上建议加上，否则windows.h里的min和max宏会和标准库的std::min、std::max冲突，报错信息很难看懂。WIN32_LEAN_AND_MEAN则是为了跳过一些用不上的老组件，加快编译。
编译器方面，MSVC 需要/EHsc开启标准异常处理，GCC 和 Clang 侧要留意-Wall -Wextra下的警告，尤其是ioctl那块的结构体初始化，没memset干净的话会有未初始化字段的提示。另外 ARM 平台上<cpuid.h>不存在，条件编译的宏要写对，__x86_64__和__i386__两个都要判断，漏一个在某些 32 位环境上编不过。
6. 常见问题与排查实录
6.1 问题速查表
| 现象 | 可能原因 | 排查手段 | 处理方式 |
|---|---|---|---|
| Windows 上 WMI 查询返回拒绝访问 | 没调用 CoSetProxyBlanket | 看 HRESULT 是不是 0x80070005 | 补上代理安全设置 |
| Linux 读 product_uuid 报权限不足 | 该文件权限为 0400 | ls -l /sys/class/dmi/id/ | 降级到 /etc/machine-id |
| 采集到的 Mac 每次运行都不同 | 命中了虚拟接口或随机化地址 | 打印接口名和 IfType | 加 device 节点判断过滤 |
| 双系统机器码对不上 | 格式未归一化 | 对比两端的原始字符串 | 统一小写去分隔符 |
| 容器里采集不到任何网卡 | veth 没有 device 软链接 | ls /sys/class/net/*/device | 容器场景改用宿主 machine-id |
| 同批电脑指纹重复 | 用了 ProcessorId 做主键 | 多台机器跑一遍对比 | 改为 UUID + Mac 组合 |
| ARM 板读不到 Serial | 厂商去掉了该字段 | cat /proc/cpuinfo全量看一遍 | 改用芯片唯一 ID 派生 |
| 程序跑久了内存上涨 | WMI 接口对象未 Release | 用任务管理器看提交大小 | 逐层补 Release 调用 |
6.2 改了三遍代码才搞定的几个坑
第一个坑是网卡切换导致的指纹漂移。有个客户反馈，笔记本插上网线之后授权失效了，拔掉就恢复。原因是他的机器同时有有线和无线两块网卡，我的代码取的是列表里第一块"处于连接状态"的网卡，插网线之后有线网卡启动，跑到了列表前面，被选中了，指纹自然变了。解决办法有两个方向：一是把所有符合条件的网卡地址都收集起来，排序后取字典序最小的那个，这样无论哪块网卡在线，选中的都是同一块；二是把全部地址都参与哈希，这样无论插不插网线都能算出同一个值，代价是换一块网卡就会失效。我最后选的是第一种，因为换网卡的场景比插网线少得多。
第二个坑是接口名排序不稳定。Linux 上我一开始直接按readdir返回的顺序取第一个，测试环境跑了十几次都没问题，上了生产环境发现有台机器每次采集结果都不一样。查了半天，原因是readdir返回的顺序取决于文件系统内部的哈希，同一目录在不同内核版本下顺序可能不同。加了一次显式排序之后彻底稳定了。这个坑很小，但排查起来很费时间，因为现象是偶发的。
第三个坑是权限降级没做好。一开始的设计是 product_uuid 读不到就直接返回空字符串，结果在容器里跑的时候，因为读不到 product_uuid，整个指纹都变成了空。后来加上了 machine-id 的降级，并且在日志里明确打印了"降级路径"，运维一眼就能看出实际用的是哪个字段。
采集逻辑里凡是涉及"读不到"的分支，都建议打一条明确的日志，写清楚读的是哪个路径、失败原因是什么。这类问题在客户现场没法调试，日志是唯一的线索来源。
线上跑的这段时间，我最大的体会是这类采集代码的复杂度根本不在于 API 本身，而在于"环境有多少种"。物理机、虚拟机、容器、双系统、多网卡、云主机，每一种都有自己的一套规则。所以别指望写一份代码处处都能用，把降级路径设计好，把失败情况当成正常路径来处理，比追求一个"万能方案"务实得多。另外，采集结果的归一化和哈希逻辑一定要和采集逻辑分离，前者是纯函数，可以写单元测试覆盖各种格式输入，后者才需要真机验证，这样能省掉大量的回归测试时间。
