CoCreateGuid是Windows下最轻量可靠的GUID生成方式，无需COM初始化，直接由系统内核生成符合RFC 4122的唯一随机UUID；而MachineGuid是注册表中静态机器标识，重装或克隆后可能重复，不适用于过程级唯一场景。
是 Windows 上最轻量、最可靠的原生方式，无需注册表读取或第三方库，直接由系统内核生成符合 RFC 4122 的 GUID。
为什么不用注册表读取 MachineGUID？
注册表路径
存的是机器级静态标识，不是每次调用都新生成的 UUID。它在系统安装时写入，重装系统或某些镜像克隆场景下可能重复，不适合用作“过程唯一标识”或“会话 ID”。
则是真随机（基于 RDRAND + 系统熵）+ 时间戳 + MAC 地址（可选）组合生成，满足唯一性要求。
必须初始化 COM 吗？
不需要显式调用
或
——
是一个纯函数，内部不依赖 COM 套间（apartment），也不触发 DLL 加载或线程模型初始化。实测在裸 main 函数、静态库、甚至 MinGW 编译的无 CRT 程序中均可直接调用。
错误认知：认为必须先
，否则失败 → 实际上该调用对
完全冗余
注意点：返回值为
，非零表示失败（极罕见，通常因内存损坏或严重系统异常）
头文件只需
，链接时隐式依赖
（MSVC 默认带；MinGW 需加
）
格式化输出时容易踩的字节序和大小写坑
GUID 结构体
的
~
是小端整数，但标准字符串格式（如
）要求按网络字节序（大端）显示。Windows SDK 的
可自动处理，但手动
更常用也更可控：
C知道
CSDN推出的一款AI技术问答工具
下载
（DWORD）必须用
，不能用
→ 大写十六进制是规范要求，部分服务端校验严格区分大小写
和
同理，用
和
混用会导致第三段小写（如
），虽合法但易引发比对失败
是字节数组，必须逐字节用
，且顺序不能颠倒（索引 0~7 对应字符串后 8 组中的前 2 字节、次 2 字节……）
缓冲区长度至少 39 字节（32 字符 + 4 连字符 + \0），
定义为 64 是稳妥做法
跨平台可移植性差？别硬套 Linux 的 uuid_generate
Linux 的
来自 libuuid，其输出是 raw 16 字节，格式化逻辑需自行实现；而 Windows 的
输出结构体，字段语义清晰。强行封装统一接口时，常见错误是把两者都转成字符串再比较——这掩盖了底层差异：
立即学习
“
C++免费学习笔记（深入）
”；
libuuid 默认生成 version 1（时间戳型）或 version 4（随机型），取决于编译选项和系统配置；
固定为 version 4
某些嵌入式环境或容器中，libuuid 可能缺失或不可靠，但
在所有 NT 内核系统（Win7+）均稳定可用
若项目已用 CMake，建议按平台条件编译：
（Windows） vs
（Linux）
实际使用中，真正难处理的不是生成，而是后续的存储与传输：比如写入日志时要不要带花括号、JSON 序列化是否需要引号包裹、数据库字段用
还是二进制
——这些细节比调用本身更容易引发线上问题。
CoCreateGuidHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuidCoCreateGuidCoCreateGuidCoInitializeCoInitializeExCoCreateGuidCoInitialize(NULL)CoCreateGuidHRESULT#include ole32.lib-lole32GUIDData1Data3xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxStringFromGUID2_snprintfData1%08X%08xData2Data3%04X%04xab12Data4[8]%02XGUID_LENuuid_generateCoCreateGuidCoCreateGuidCoCreateGuidtarget_link_libraries(myapp PRIVATE ${CMAKE_DL_LIBS} ole32)uuidCHAR(36)BINARY(16)