生成标识符
生成版本 1、3、4、5、6、7 的 UUID 或 ULID，可逐个生成或一次最多一千个；也可以分析任意标识符，了解其版本、变体以及其中包含的时间。所有计算都在你的浏览器中使用系统的加密随机数生成器完成。
122 位随机数。只需要唯一标识符时最常用的选择。
格式
结果
分析 UUID 或 ULID
支持连字符、花括号、urn:uuid: 前缀或 26 个字符的 ULID
类型
版本 7：可排序的 Unix 时间
变体
RFC 9562（原 RFC 4122）
创建时间
2022年2月22日 16:22:22 2022-02-22T19:22:22.000Z · 1645557742000 ms
规范形式017f22e2-79b0-7cc3-98c4-dc0c0c07398f
大写017F22E2-79B0-7CC3-98C4-DC0C0C07398F
带花括号的 GUID{017F22E2-79B0-7CC3-98C4-DC0C0C07398F}
URNurn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f
作为 ULID01FWHE4YDGFK1SHH6W1G60EECF
十六进制017f22e279b07cc398c4dc0c0c07398f
十进制整数1989357241971137676463954034883508623
Base64AX8i4nmwfMOYxNwMDAc5jw==

工作原理

UUID 是一个 128 位的数字，写成分为五组（8-4-4-4-12）的 32 个十六进制数字。它无需询问任何人该值是否已被使用就能标识一条记录：两台服务器、两个移动应用或两个进程可以同时生成标识符，无需协调也不会冲突。其格式由 RFC 9562 定义，该标准于 2024 年取代 RFC 4122，并新增了版本 6、7 和 8。

第三组开头的数字表示版本，每个版本排列位的方式都不同。版本 4 是纯随机数。版本 7 以毫秒级时间开头，因此标识符按创建顺序排列。版本 3 和 5 没有任何随机成分：它们由命名空间和名称的哈希生成，所以结果总是相同。版本 1 和 6 包含精度为 100 纳秒的时间以及一个节点，这个节点在历史上是计算机的 MAC 地址。

分析器则反向工作：读取版本和变体，从 v1、v6、v7 UUID 以及 ULID 中还原时间，并把同一个值显示为 GUID、URN、十六进制、整数或 Base64。所有计算都在你的浏览器中完成，不会有任何标识符发送到服务器。

示例

v5 · DNS · www.example.com2ed6657d-e927-568b-95e1-2665a8aea6a2这是 RFC 9562 的测试向量。任何正确实现版本 5 的库，对于 DNS 命名空间中的这个名称都必须返回完全相同的值。
017F22E2-79B0-7CC3-98C4-DC0C0C07398F2022-02-22T19:22:22.000Zv7 UUID 的前 12 位是十六进制的 Unix 毫秒数：0x017F22E279B0 即 1645557742000。
C232AB00-9414-11EC-B3C8-9F6BDECED8461EC9414C-232A-6B00-B3C8-9F6BDECED846同一时刻分别表示为版本 1 和版本 6。版本 6 把时间位按从高到低重新排列，使文本按时间顺序排序；时钟序列和节点不变。
01ARZ3NDEKTSV4RRFFQ69G5FAV01563e3a-b5d3-d676-4c61-efb99302bd5bULID 与 UUID 同样占用 128 位，因此可以存入 uuid 列。但它没有版本和变体：按 UUID 读取时，这些数字只是随机部分的一部分。

使用场景

  • 在客户端或多个服务中同时生成主键，无需等待数据库分配自增值。
  • 生成幂等键，避免重试的付款或订单被处理两次。
  • 为每个请求打上关联 ID，以便在多个微服务的日志中追踪它。
  • 用 v5 从自然键（邮箱、URL、SKU）派生稳定的标识符，让两个系统无需共享表也能得到相同的值。
  • 当 v7 UUID 或 ULID 出现在日志或错误报告中时，据此得知记录的创建时间。
  • 一次性用数百个有效标识符填充测试数据。

常见问题

主键用 v4 还是 v7？

除非你有理由隐藏创建时间，否则用 v7。B 树索引按顺序存储键，而 v4 会落在索引的任意位置：每次插入都会触及不同的页，导致页分裂，缓存效率也更低。v7 则总是追加到末尾，就像自增值一样。注意 SQL Server：uniqueidentifier 类型从最后六个字节开始比较排序，所以在那里 v7 也不是顺序的。

两个 v4 UUID 会重复吗？

理论上会，实际上不会。v4 有 122 个随机位，要让至少出现一次重复的概率达到 50 %，大约需要生成 2.7 × 10¹⁸ 个，也就是每秒十亿个、持续 85 年以上。前提是使用加密随机数生成器：现实中报告的重复都来自初始化不当的种子，而不是数学本身。

UUID 和 GUID 是一回事吗？

是的，GUID 是 Microsoft 使用的名称，文本完全相同；在 Windows 中通常以大写并加花括号显示。区别在于二进制形式：.NET 的 Guid.ToByteArray 以小端序存储前三组，所以如果你在其他语言中读取这些原始字节，会看到开头的数字是反的。

可以把 UUID 当作秘密令牌吗？

正确生成的 v4 含有 122 个不可预测的位，足以用作难以猜测的链接；但 RFC 9562 明确指出 UUID 并非为凭据设计：许多库并不保证使用加密随机数生成器，而版本 1、6、7 会暴露创建时间。对于会话令牌或密码重置令牌，最好生成专用的随机字节。

ULID 还是 UUID v7？

两者携带的信息几乎相同：48 位毫秒时间，其余为随机数。ULID 用 26 个字符书写，没有连字符和易混淆字母，放在 URL 里更方便。v7 是标准 UUID，因此无需转换即可放入 PostgreSQL 的 uuid 列并通过任何校验器。如果你从零开始且数据库支持 uuid 类型，选 v7。

为什么我的 v1 UUID 的节点不是我的 MAC？

因为暴露网卡的 MAC 可以追踪每个标识符是由哪台机器生成的，1999 年 Melissa 病毒的作者就是这样被查出来的。RFC 9562 建议使用设置了多播位的随机节点，本工具正是这么做的；当 v1 UUID 包含真实 MAC 时，分析器会提醒你。

另请参阅