UUID 生成器（v4 与 v7）

怎么用

1. 选择版本：只要一个随机标识就选 v4；要做数据库主键，或者需要按生成先后排序，就选 v7。
2. 填写数量，1 到 1000 之间。
3. 选格式：带连字符的小写是标准写法；「大写」「去掉连字符」「加花括号」用于那些要求特定写法的系统，比如一些微软的老工具。
4. 点「生成」，然后「复制」整份列表，或者「下载」成文本文件，每行一个。
5. 要查看已有的 UUID，把它粘贴到「解析 UUID」里。连字符、花括号、大写和 urn:uuid: 前缀都能识别。

UUID 的原理

UUID 是一个 128 位的数，写成 32 位十六进制数字，按 8-4-4-4-12 分成五组。现行标准是 2024 年发布的 RFC 9562，它取代了 RFC 4122，并新增了第 6、7、8 版。每个标准 UUID 里有两处是固定的：第三组的第一位数字表示版本；第四组的第一位数字总是 8、9、a 或 b 之一，表示变体。所以只看这两位，就能认出一个 UUID 是哪一种。

第 4 版：随机

除去这 6 个固定位，v4 UUID 的其余 122 位全是随机数。本页从浏览器的密码学安全随机数生成器取随机数，和 crypto.randomUUID 用的是同一个来源。可能的取值多到重复几乎不可能发生：要生成大约 2.71 × 10^18 个 UUID，其中任意两个相同的概率才会达到一半。

第 7 版：按时间排序

v7 UUID 以一个 48 位的 Unix 毫秒时间戳开头，后面依次是版本号、74 位随机数和变体。因为时间在最前面，v7 UUID 按字典序排列就是按生成先后排列。这对数据库很重要：随机的 v4 主键会被插到 B 树索引的各个位置，造成页分裂和碎片；v7 主键则总是追加在末尾，索引更紧凑，写入更快。正因如此，PostgreSQL 18 内置了 uuidv7() 函数。48 位时间戳可以一直用到公元 10889 年。

在同一毫秒内批量生成 v7 时，本工具把随机部分当作计数器，每生成一个就加 1。这是 RFC 9562 描述的方法之一，保证一批结果严格递增。

怎样解析 UUID

解析器读取版本位和变体位；对于第 1、6、7 版，还会解出其中的时间戳。第 1 版和第 6 版记录的是从 1582 年 10 月 15 日（格里历启用之日）起经过的 100 纳秒间隔数，第 7 版记录的是从 1970 年起的毫秒数。全 0 的 Nil UUID 和全 1 的 Max UUID 是标准定义的两个特殊值。

算例

下面是 RFC 9562 附录里的示例 UUID，它们都在同一时刻生成：2022 年 2 月 22 日 19:22:22（UTC），也就是北京时间 2022 年 2 月 23 日 03:22:22。

在 v7 示例里，前 12 位 017F22E279B0 是 1645557742000 的十六进制形式，也就是从 1970 年到那一刻的毫秒数；第二个连字符后面的 7 是版本号，第三个连字符后面的 9 是变体。

同一个 v4 UUID 的四种写法：919108f7-52d1-4320-9bac-f847db4148a8、919108F7-52D1-4320-9BAC-F847DB4148A8、919108f752d143209bacf847db4148a8 和 {919108f7-52d1-4320-9bac-f847db4148a8}。解析结果完全相同。

局限

• 一次最多 1000 个。 超出部分会被截掉，需要更多就再生成一次。
• v7 会暴露生成时间。 任何看到 UUID 的人都能读出它是什么时候生成的。如果标识会出现在公开链接里，而注册时间之类的信息不该公开，请用 v4。
• v7 依赖设备时钟。 设备时间不准，时间戳就不准；在不同机器上生成的 UUID，有序程度取决于这些机器的时钟是否一致。
• 第 1、3、5、6、8 版只能解析，不能生成。 第 1、6 版含有设备标识；第 3、5 版由名称计算得出，应当由管理该命名空间的系统生成。

参考资料

• RFC 9562：通用唯一标识符（UUID）（英文）
• MDN：Crypto.randomUUID()
• PostgreSQL 18 文档：UUID 函数（uuidv7，英文）