UUID 生成器 — v4、v7、ULID 和 NanoID，附解码器

批量生成 UUID v4 或按时间排序的 v7、ULID 和 NanoID，或粘贴一个 ID 查看其版本和内嵌的时间戳。

数量（1–10,000）

大写不带连字符大括号 {…}

生成的 UUID v4

验证并解码 ID

UUID、GUID 或 ULID

UUID 版本 7（按 Unix 时间排序）

规范形式	017f22e2-79b0-7cc3-98c4-dc0c0c07398f
版本	7 — 按 Unix 时间排序
变体	RFC 9562 / RFC 4122
rand_a (12 bits)	cc3
时间戳	2022-02-22T19:22:22.000Z Unix 毫秒 1645557742000

ID 通过 crypto.getRandomValues 在你的浏览器中生成。不会发送或保存任何内容。浏览全部免费工具.

发现问题，或者觉得哪里可以更好？每条消息我们都会阅读，并尽快修复。

这款 UUID 生成器可以生成随机的第 4 版 UUID、RFC 9562 定义的按时间排序的第 7 版 UUID、ULID 和 NanoID，可以一次生成一个，也可以批量生成最多 10,000 个并复制或下载。每一个随机位都来自浏览器的密码学随机数生成器 crypto.getRandomValues，而不是 Math.random。下方的解码器可以接受任意 UUID、GUID 或 ULID，告诉你它的版本和变体；对于 v1、v6、v7 和 ULID，还能告诉你它的创建时间。

同一批次中的第 7 版 UUID 和 ULID 严格递增，即使成千上万个 ID 共享同一毫秒也是如此，因此它们会按创建顺序排序，正如数据库主键所需要的那样。本工具不提供第 1 版：浏览器无法访问 MAC 地址或持久的时钟序列，所以在网页中生成的 v1 UUID 只能模仿其格式。如果你需要 v1 或基于名称的 v3/v5 UUID，请用你所用语言的 UUID 库生成。

使用方法

选择类型：通用随机 ID 用 v4，数据库主键用 v7，如果你的技术栈使用 ULID 或 NanoID 则选它们。
设置需要的数量（最多 10,000），然后点击“生成”（或在数量框中按 Enter）。
选择格式：大写、不带连字符，或用大括号包裹（适用于 Windows 注册表和 .NET 场景）。
全部复制，或下载为每行一个 ID 的文本文件，或下载为 JSON 数组。
要检查已有的 ID，把它粘贴到解码器中，即可查看其版本、变体以及包含的时间戳。

常见问题

UUID v4 和 v7 有什么区别？

v4 UUID 是 122 个随机位，没有任何结构。v7 UUID 在开头放置一个以毫秒为单位的 48 位 Unix 时间戳，后面跟 74 个随机位，所以 v7 的值按创建时间排序。这种有序性让 v7 更适合作为数据库主键：新行会追加到索引末尾，而不是随机位置，从而减少页分裂，保持插入速度。代价是 v7 ID 会暴露它的创建时间。

两个 UUID 会相同吗？

理论上会，实际上不会，前提是它们来自优质的随机源。有 122 个随机位时，需要生成约 270 京（2.7 × 10^18）个 v4 UUID，才有 50% 的概率出现一次碰撞。实际出现的重复都源于 bug：弱的或种子不当的随机数生成器、复制的虚拟机状态，或重复使用同一个值的代码。

GUID 和 UUID 是一回事吗？

是的。GUID 是 Microsoft 对同一种 128 位标识符的叫法，现代 GUID 就是标准的 UUID（通常是第 4 版）。唯一的区别在于呈现方式：Windows 工具常以大写并用大括号包裹的形式显示 GUID，例如 {3F2504E0-4F89-41D3-9A0C-0305E82C3301}。使用大写和大括号选项即可匹配这种格式。

应该用 UUID v7 还是 ULID？

两者都是 128 位、按时间排序，并带有毫秒级时间戳。UUID v7 适用于任何已有 UUID 列或类型的地方，例如 PostgreSQL 的 uuid 类型或 Java 的 UUID 类。ULID 的文本形式更短（26 个字符而不是 36 个）且不区分大小写，但需要专门的库，并以文本或二进制形式存储。如果你的数据库和语言本来就支持 UUID，v7 是更简单的选择。

NanoID 应该多长？

默认使用 64 字符的 URL 安全字符集生成 21 个字符，提供 126 位随机性，与 UUID v4 的 122 位相当。如果 ID 数量很少，且被猜中也无妨（例如有限流保护的短链接），更短的 ID 也可以。长度滑块下方显示的位数会告诉你舍弃了多少；64 个符号的字符集中，每个字符提供 6 位。

能看出 UUID 是什么时候创建的吗？

只有基于时间的版本可以。把 ID 粘贴到解码器中：v7 和 ULID 在前 48 位中存储 Unix 毫秒数，v1 和 v6 存储自 1582 年 10 月 15 日以来的 100 纳秒间隔数。v4 UUID 完全不包含时间，只有随机位以及版本和变体标记。

读懂 UUID：版本与变体

UUID 写作 32 个十六进制数字，按 8-4-4-4-12 分组。有两个位置用于识别它。第三组的第一个数字是版本：在 0190a3c4-1b2c-7d3e-8f40-0123456789ab 中是 7。第四组的第一个数字编码了变体：8、9、a 或 b 表示标准的 RFC 9562 布局，如今几乎所有 UUID 都使用这种布局。

• v1：格里历时间戳加上生成机器的 MAC 地址。两者都会泄露；新系统很少使用。

• v3 和 v5：确定性的，由命名空间和名称通过 MD5（v3）或 SHA-1（v5）派生。相同的输入总是得到相同的 UUID。

• v4：随机。大多数库的默认版本。

• v6：重新排列了时间戳以便排序的 v1；为 v1 用户提供的迁移方案。

• v7：Unix 毫秒时间戳加随机位。新系统推荐使用的按时间排序版本。

• v8：由厂商自定义布局；只有版本位和变体位是固定的。

为什么随机 UUID 会拖慢数据库，以及 v7 如何解决

大多数数据库用 B 树索引存储主键。使用顺序键时，每个新行都落在索引最右侧的页上，而这一页始终在内存中。使用随机 v4 UUID 时，每次插入都落在随机的页上；一旦索引大于内存，插入就开始从磁盘读取页面并进行分裂，写入吞吐量随之下降。按主键聚簇整张表的 MySQL InnoDB 对此感受最明显。

UUID v7 保留了 UUID 的优点（全局唯一、任何客户端无需往返通信即可生成、可以安全公开），同时在索引中的表现几乎和自增列一样。2024 年 5 月发布的 RFC 9562 推荐新的基于时间的 ID 使用 v7 而不是 v1 和 v6，PostgreSQL 18 也新增了内置的 uuidv7() 函数。

请用原生的 16 字节类型存储 UUID（PostgreSQL 中的 uuid，MySQL 中的 BINARY(16)），而不是 36 个字符的字符串，后者会让索引大小增加一倍多。

UUID、ULID 与 NanoID 一览

• UUID v4：36 个字符，122 个随机位，各种库和数据库普遍支持，不可排序。

• UUID v7：36 个字符，48 位毫秒时间加 74 个随机位，可排序，凡支持 UUID 的地方都支持。

• ULID：26 个 Crockford Base32 字符，48 位时间加 80 个随机位，可排序且不区分大小写，需要专门的库。

• NanoID：默认 21 个字符，字符集和长度任意，URL 安全且紧凑，没有时间戳，也没有标准的二进制形式。