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