UUID 的用途
UUID（Universally Unique Identifier，通用唯一标识符）在 Microsoft 生态中也常称为 GUID，是一个 128 位值，标准文本形式例如：
550e8400-e29b-41d4-a716-446655440000
当系统需要在没有中央分配器的情况下、碰撞概率极低的标识符时，就会使用 UUID：分布式服务中的数据库主键、消息 ID、上传句柄，以及 API 中的资源名。唯一性是概率性的（或由名称推导），而不是每次生成 ID 时都向全局注册表查询来证明。
可用 生成 UUID 先生成示例，再用 校验 UUID 检查格式与版本字段。
本系列中的子工具
- 生成 UUID — 创建版本 1、3、4 或 5 的 UUID；在需要时提供可选的 namespace 与 name 输入。
- 校验 UUID — 验证字符串是否符合 UUID 布局，并针对版本 1 到 5 报告有效性相关考量。
生成与校验相辅相成：按 schema 期望的版本生成 ID，再在把用户提供或导入的字符串当作外键或缓存键之前进行校验。
实际会遇到的版本
版本 4（随机）。 新应用 ID 最常见的选择。多数位来自 CSPRNG；版本位与变体位按 RFC 4122 固定。在生成器可靠的前提下，实际体量下的碰撞可忽略。
版本 1（基于时间）。 嵌入时间戳与节点标识（历史上多为 MAC 地址）。适合需要粗略时间排序的场景，但可能泄露创建时间与机器身份——注重隐私的场景往往更倾向 v4 或更新方案。
版本 3（基于名称的 MD5）与版本 5（基于名称的 SHA-1）。 由 namespace UUID 加上 name 字符串推导 UUID。相同的 namespace+name 始终得到相同 UUID——便于从 URL 或用户名得到稳定 ID，而无需查找表。新设计优先 v5 而非 v3，因为推导使用 SHA-1 而非 MD5。
其他版本与后续提案（例如较新 RFC 中可按时间排序的 UUIDv7）会出现在现代技术栈中；若平台文档指定了某一版本，应遵循该约定，而不是自行混用。
文本格式与变体位
规范文本使用五个十六进制分组 8-4-4-4-12。解析器应接受大写或小写十六进制。版本半字节位于第三组；变体位位于第四组。仅检查「看起来像带连字符的十六进制」弱于同时检查所声称类型的版本/变体一致性。
部分 API 接受 URN 形式（urn:uuid:…）或以花括号包裹的 GUID {…}。比较前请先规范化。二进制存储为 16 字节；文本形式面向人与 JSON。
明智地选择 ID
UUID 有帮助时。 便于合并的主键、离线发放 ID、对客户端隐藏顺序行号。
UUID 有害时。 巨大的随机主键相对顺序整数可能更严重地碎片化 B-tree 索引——请针对你的数据库实测。若每个 ID 都不透明，日志与客服会更困难；在运维需要时，可搭配面向人的工单号。
稳定性。 对基于名称的 v3/v5，请文档化组织统一使用的 namespace UUID（DNS、URL、OID 或自定义根）。更改 namespace 会在静默中为同一 name 生成不同的 ID。
安全说明
UUIDv4 值是标识符，不是身份验证密钥。即便如此，猜测未公开的 v4 ID 仍然困难——不要把它本身当作授权；务必另行执行访问控制。若基于 MAC 的节点位会在公开文档中暴露硬件身份，请避免 v1。不要把密码或 PAN 嵌入 v3/v5 的 name 字符串。
常见错误
- 生成 v4 却只保存前半段「以节省空间」，破坏唯一性保证。
- 在规范化方式不同的系统之间做区分大小写的字符串比较。
- 将空 UUID（nil UUID，
00000000-0000-0000-0000-000000000000）当作真实实体键。 - 假定格式校验通过就意味着该 ID 存在于数据库中。
- 对同一列混用多种具有不同版本策略的生成器。
限制与运行环境
这些工具帮助你在浏览器中生成并检查符合 RFC 风格的 UUID，用于开发与学习。它们不会从生产数据库序列分配 ID，也不能在 RNG 损坏时保证全局唯一性。
小结
UUID 以标准十六进制形式提供 128 位标识符，并提供随机、基于时间与基于名称的生成版本。本中心将多版本生成器与校验器搭配使用，便于创建符合 schema 的 ID，并尽早拒绝格式错误的字符串。一般用途优先 v4，稳定的名称派生 ID 优先 v5，并且始终将授权与标识符的不透明性分开处理。