RFC 4122 UUID格式合法性验证应使用正则^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$，仅校验36字符、4个短横线及各段位数，不涉及版本或变体语义校验。
直接用正则判断UUID格式是否合法
RFC 4122 明确规定UUID字符串必须是 32 个十六进制字符，中间用 4 个短横线分隔，共 5 段：8-4-4-4-12。最简且足够可靠的验证方式就是正则匹配——不依赖外部库，不解析二进制结构，只校验文本格式。
常见错误是忽略大小写（RFC 允许 a–f 和 A–F），或漏掉末段的 12 位（比如误写成 8-4-4-4-8）；还有人用 std::uuid（C++26 尚未落地，libuuid 又非标准），反而引入不必要的依赖和平台差异。
- 推荐正则表达式：
"^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$" - 用
std::regex_match(str, pattern)即可，注意传入std::regex_constants::ECMAScript（默认即可） - 若需高性能批量校验（如日志解析），可改用手工遍历：检查长度是否为 36，再逐字符比对位置和分隔符，避免正则引擎开销
区分“格式合法”和“语义合法”
正则只能保证是 RFC 4122 的字符串格式，但无法判断版本号、变体（variant）是否合规。例如 "00000000-0000-0000-0000-000000000000" 格式正确，却是nil UUID；"123e4567-e89b-12d3-a456-426614174000" 中第13位是 1，表示版本 1，符合规范；而若此处是 9，就违反了版本字段定义。
真正按 RFC 4122 解析语义，需提取第13–16位（版本字段）和第17–20位（变体字段），并做位运算判断：
立即学习“C++免费学习笔记（深入）”；
- 版本字段（第13–16位，即字符串索引 14–15）：应为
1、2、3、4或5（对应 time-based、DCE security、MD5 hash、random、SHA-1 hash） - 变体字段（第17–20位，即字符串索引 19–20）：高两位必须是
10xx（即十六进制值8–b），否则不是 RFC 4122 变体 - 若业务只要求“能被下游系统接受”，通常格式校验已足够；只有在安全敏感或协议网关场景，才需进一步校验版本/变体
Windows 下用 UuidFromStringA 的坑
Windows SDK 提供 UuidFromStringA，但它**不验证版本和变体**，只做基本解析+格式清洗（比如允许省略短横线）。更麻烦的是：它会把非法字符串（如含空格、长度不足）静默转成全零 UUID，且返回 RPC_S_OK，导致误判。
- 调用后必须额外检查结果是否为 nil UUID（所有字节为 0），否则可能把
"garbage"当作有效 UUID - 它不支持 Unicode 输入（
UuidFromStringW行为类似），且跨平台不可用，建议仅在遗留 Win32 项目中谨慎使用 - 替代方案：用正则先过滤，再用
UuidFromStringA做二次解析（仅当需要后续二进制操作时）
用 boost::uuids::string_generator 需注意异常粒度
Boost.UUID 的 string_generator 在输入非法时抛出 boost::uuids::invalid_string 异常，看似方便，但它对“非法”的定义比 RFC 更宽——比如拒绝带空格的字符串，哪怕正则能过；而且异常开销较大，不适合高频校验场景。
- 若已引入 Boost，可用它做最终解析（例如后续要调用
to_string()或比较），但**不要用它做第一道校验** - 务必用
try/catch包裹，且不要假设异常类型只有这一种（某些 Boost 版本在内存失败时可能抛std::bad_alloc） - 注意：
boost::uuids::nil_uuid()是合法对象，不代表输入非法；判断是否为 nil 需显式调用is_nil()
真正难的不是写对正则，而是想清楚你要拦住哪类错误：是防止 JSON 解析崩溃（格式即可），还是确保发给 Kafka 的事件 ID 符合服务端要求（需版本/变体）？后者往往需要读取 RFC 4122 第 4.1.2 节的位布局图，手动解包 hex 字符串的特定字节。
