免费在线 UUID 生成器
UUID 对于数据库主键、请求跟踪和分布式系统至关重要。 Dokall 生成符合 RFC 标准的 UUID v4（随机）和 UUID v7（时间排序）值，您可以一键复制。
生成单个 UUID 或批次进行测试。所有生成都在您的浏览器本地进行 - 快速、私密且无速率限制。
什么是 UUID？
UUID（Universally Unique Identifier，通用唯一标识符）是一个 128 位值，格式为五组共 32 个十六进制数字，以连字符分隔：550e8400-e29b-41d4-a716-446655440000。UUID 设计为在空间和时间上都唯一，无需中央机构分配。
UUID 用作数据库主键、API 请求标识符、分布式系统关联 ID、文件名和会话令牌。其关键优势是任何系统都可独立生成 UUID，且碰撞概率可忽略不计——约需生成 2.71 百京（quintillion）个 UUID，才有 50% 的概率出现一次碰撞。
UUID 版本说明
UUID 有多个版本，各自采用不同的生成策略。
UUID v1 将当前时间戳与机器的 MAC 地址组合。它具有唯一性，且大致按时间排序，但会泄露 MAC 地址和确切创建时间——在某些场景下存在隐私风险。
UUID v4 由密码学安全的随机数生成。128 位中有 122 位是随机的（另有 6 位编码版本和变体）。这是最常用的版本，因为简单、私密，且抗冲突能力出色。
UUID v5（以及 v3）使用 SHA-1（v5）或 MD5（v3）对命名空间和名称进行哈希，生成确定性 UUID。相同的命名空间和名称总是得到相同的 UUID，适合从自然键生成一致的 ID。
UUID v7（RFC 9562，2024）在前 48 位编码 Unix 时间戳，后接随机数据。因此 v7 UUID 天然按时间排序，同时仍保持唯一。这对数据库索引是一大优势。
UUID v4 与 UUID v7 对比
UUID v4 完全随机——没有固有顺序。作为带 B-tree 索引的数据库主键时，随机 UUID 会使写入分散到索引各处，导致缓存利用率差、I/O 增加，即所谓的索引碎片。
UUID v7 在前 48 位嵌入时间戳，使 ID 随时间单调递增。新记录追加到 B-tree 索引末尾，而不是随机散落。这大幅提升写入性能和索引局部性——基准测试中，在插入密集型工作负载下，v7 可比 v4 快 2–5 倍。
UUID v7 还能从 ID 本身提取近似创建时间戳，便于调试、排序和数据生命周期管理。代价是：v7 会暴露记录创建时间，若创建时间敏感则需留意。
对新项目而言，除非你特别需要 v4 的非顺序特性（例如防止对公网 ID 的枚举攻击），否则推荐使用 UUID v7。
将 UUID 用作数据库主键
以 UUID 作为主键有明显优势：可在客户端生成而无需往返数据库；跨表、跨库唯一；且不暴露记录数量或创建顺序（v4）。因此非常适合分布式系统、离线优先应用，以及不宜暴露顺序 ID 的 API。
缺点是：UUID 为 16 字节，而整数 ID 通常为 4–8 字节，会增加存储、内存占用和连接成本。字符串形式（36 个字符）在基于文本的存储中更大。随机 UUID（v4）还会造成上文所述的 B-tree 索引碎片。
实用建议：使用 UUID v7 以避免索引碎片。将 UUID 存为 binary(16) 或原生 UUID 类型（PostgreSQL 有 uuid 类型），而不是 varchar(36)。若数据库支持，使用 UUID 类型可获得更好的存储和比较性能。
UUID 与自增、ULID、Nano ID 对比
自增 ID（SERIAL、IDENTITY）是由数据库分配的顺序整数。紧凑（4–8 字节）、索引快、易读。缺点：生成需要往返数据库；会暴露记录数量和创建顺序；且跨表或跨库不唯一。
UUID 全局唯一，可在任意处生成。缺点：存储更大（16 字节），且 v4 会造成索引碎片（可由 v7 解决）。
ULID（Universally Unique Lexicographically Sortable Identifier）是 128 位 ID，带 48 位时间戳前缀，类似 UUID v7，但字符串表示更紧凑（26 个 Crockford Base32 字符，对比 36 个十六进制字符）。ULID 可按时间进行字典序排序。
Nano ID 可生成可配置字母表和长度的随机字符串 ID。21 字符的 Nano ID 抗冲突能力大致与 UUID v4 相当，但更短。适合需要 URL 友好 ID、又不需要完整 128 位 UUID 格式的场景。
简单单库应用可选自增；分布式系统或 API 可选 UUID v7；在意字符串长度时可选 ULID 或 Nano ID。