UUID v7 生成器
在浏览器中批量生成 RFC 9562 标准的 UUID v7 ——前 48 位内嵌毫秒级时间戳，使 ID 可按生成顺序排序。支持标准、大写、无连字符、带花括号、URN 等多种格式，且可直接存入现有的 UUID 类型列。
UUID v7、UUID v4 与 ULID 的比较
| 形式 | 长度 | 是否可按生成顺序排序 | 与现有 UUID 类型列的兼容性 | 说明 |
|---|---|---|---|---|
| UUID v7 | 36 个字符（含 4 个连字符） | 是（前 48 位为毫秒级时间戳） | 有（保持标准 UUID 类型、十六进制表示） | 由 RFC 9562 标准化。由 Unix 时间戳与随机值组成，兼顾按时间顺序排序与既有 UUID 资产的兼容性。本工具生成的正是此格式。 |
| UUID v4 | 36 个字符（含 4 个连字符） | 否（完全随机） | 有（标准 UUID 类型） | 由 RFC 9562 标准化的完全随机 128 位标识符，不包含生成来源信息，是目前应用最广泛的形式。 |
| ULID | 26 个字符 | 是（前 10 个字符为时间戳） | 无（使用 Base32，需额外的列类型转换） | 独立于 UUID 标准（RFC 4122/9562）之外的 Crockford Base32 规范。比 UUID v7 更短，但无法直接存入原生 UUID 类型列。 |
什么是 UUID v7
UUID v7 是2024年5月由 IETF 在 RFC 9562 中标准化的、可按时刻排序的新型 UUID（Universally Unique Identifier）。此前广泛使用的 UUID v4，其128位全部为完全随机值，因而没有线索可循生成顺序；而 UUID v7 在前48位带有毫秒级的 Unix 时间戳，只需作为字符串排序即可按生成顺序排列。其余位由随机值填充，因此即便在同一毫秒内生成多个，唯一性仍得以保持。
本工具使用 Web Crypto API 在浏览器内生成 UUID v7，并以标准、大写、无连字符、花括号、URN 形式中的任一种批量输出。该表记与既有的面向 UUID v4 的数据库列完全兼容，无需变更字段类型即可直接保存，这正是其特点。若想确认生成的值是否按时间戳排列，可用姊妹工具UUID v7 解码工具取出其中嵌入的时刻进行核对。
UUID v7 的生成步骤
- 指定生成件数 在“生成件数”中输入一次所需的 UUID v7 个数。若想批量制作测试数据，可指定多件。
- 选择显示形式 按保存目标数据库或系统的规格，从标准、大写、无连字符、花括号、URN 形式中选择。
- 按下“生成”按钮 会由浏览器内的 Web Crypto API 即时生成，并在结果栏中列出。不会向服务器发送。
- 复制结果 可逐条使用“复制”按钮，若要整体使用则用“全部复制”按钮取入剪贴板。
用好本工具的小技巧
- 生成的 UUID v7 全部在浏览器内通过 JavaScript（Web Crypto API）处理，不会发送到 toolbase.cc 的服务器。
- UUID v7 的前 48 位是毫秒级 Unix 时间戳，因此只需按字符串排序即可还原生成时刻的先后顺序。
- 可直接存入现有存放 UUID v4 的数据库列（如 CHAR(36) 或 PostgreSQL 的 uuid 类型），迁移时无需改动应用层的类型定义。
- 「无连字符」格式便于用作 URL 路径段或文件名；「带花括号」格式则与 Windows COM/注册表中使用的 GUID 表示法一致。
- 如果在 UUID v7 与 ULID（Crockford Base32、26 个字符）之间犹豫不决：现有系统已假定使用 UUID 类型列时选 UUID v7，追求更短字符串时选 ULID。
UUID v7 派上用场的场景
数据库主键设计
相比 UUID v4，插入位置更易呈时间顺序，可在抑制 B-tree 索引碎片化的同时，继续沿用既有的 UUID 类型字段。
分布式系统中的 ID 采号
多台服务器与微服务无需依赖中央的序列发行者，即可各自独立生成唯一且按时刻排列的 ID。
日志、事件的标识符
将 UUID v7 用于访问日志或事件历史的 ID，仅凭 ID 的大小即可掌握大致的发生顺序，无需另设专门的时间戳列。
测试数据、虚拟记录的批量制作
在开发、验证环境中投入大量虚拟记录时，批量生成并复制后，即可直接用于 SQL 的 INSERT 语句或 API 的测试载荷。
想确认生成结果的内容时
若想核实生成的 UUID v7 是否真的嵌入了正确的时间戳，可用UUID v7 解码工具；若需要随机生成的 UUID v4，则可用UUID 生成工具应对。
UUID v7 的相关术语
- UUID v7
- 在 RFC 9562 中标准化的、前48位带有毫秒级 Unix 时间戳的 UUID 版本。既可按时刻排序，又保持了与既有 UUID 类型字段的兼容性。
- 按时间戳排序的 ID
- 指值本身含有生成时刻的信息，只需作为字符串或数值排序即可按发生顺序排列的标识符。UUID v7、ULID、Snowflake ID 等均属此类。
- 与 UUID v4 的差异
- UUID v4 的128位全部为完全随机，不含生成顺序的信息；而 UUID v7 的前48位为时间戳，故可得知生成顺序。表记形式（36个字符、十六进制）本身两者相同。
- 单调性（monotonicity）
- 指值按生成顺序单调递增的性质。UUID v7 在同一毫秒内生成多个时，视实现而定可能仅由随机部分的大小左右顺序，因此严格的单调性并非规范上的必备要件，而取决于实现。
- 索引局部性
- 指在数据库的 B-tree 索引中，新插入的值聚集于既有数据附近（多为末尾）的性质。UUID v7 的值按时间戳排列，局部性高，较之完全随机的 UUID v4 更易改善插入时的页分裂与缓存效率。
- RFC 9562
- 2024年5月由 IETF 公开的、规定 UUID 规范的标准文档。它取代了此前的 RFC 4122，并新增了可按时刻排序的 v6、v7 以及可处理自定义字段的 v8。
常见问题
闲话 ― UUID v7 如何把「时间」带回 UUID 家族
UUID v7 于 2024 年 5 月作为 IETF RFC 9562 标准化，这是自 2005 年最初的 RFC 4122 发布约二十年以来 UUID 规范的首次重大修订。此次修订新增了可排序的 v6、v7 变体，以及支持自定义字段的 v8，其背景正是 UUID v4 完全随机的特性长期以来被指出不利于数据库索引效率这一问题。
UUID v7 的设计与本站的姊妹工具 ULID 非常相似：两者都将毫秒级时间戳置于前部，其余部分以随机值填充。决定性的区别在于表示形式——ULID 采用独立于 UUID 标准之外的 26 位字符 Crockford Base32 格式，而 UUID v7 则延续了自 RFC 4122 以来的 36 位字符十六进制表示。正因如此，UUID v7 能够直接沿用既有的 UUID 类型列、库以及 API 规范而无需任何改动。
事实上，UUID v7 发布后不久便迅速获得主流数据库与语言运行时的支持。PostgreSQL 自 18 版本起内置了 uuidv7() 函数，其他主流语言与 ORM 中支持 v7 生成的库也在快速增加。「可按时间顺序排序」的便利性与「不破坏既有 UUID 资产」的兼容性能够兼得，正是 UUID v7 与 ULID 一同被迅速采纳的原因。