UUID 生成器

v4 UUID 是 122 位的加密强度随机数,是幂等键、会话 ID 等需要不透明、无顺序标识符场景下最常用的默认选择。v7 UUID 在前导字节中嵌入 48 位 Unix 毫秒时间戳,因此时间相近的值在字典序中也相近。这让 v7 更适合作数据库主键,否则插入可能会把 B-tree 索引打散。

示例

三个 v4 UUID(随机,无顺序):

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

三个在同一毫秒生成的 v7 UUID(注意共享的前缀):

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

常见错误与注意事项

以下是开发者在应用中使用 UUID 时真正会遇到的坑:

• 在依赖插入顺序的地方使用 v4。 对 1000 万个随机 v4 建索引会让 B-tree 频繁分页。若坚持用 v4,要么接受写放大,要么把主键切换到 v7。
• 去掉连字符时忽略了版本半字节。 f47ac10b58cc4372a5670e02b2c3d479 仍然是合法的 32 字符十六进制 UUID,但第 13 位(4)是版本标记,并非随机半字节。不要把整整 32 位都当作随机值。
• 依赖 Math.random()。 基于 Math.random() 的老旧库不是加密强随机,可能被预测。请使用 crypto.randomUUID()(浏览器和 Node 19+)或从 crypto 取值的 v7 库。
• 把 v7 当作时间戳使用。 前 48 位携带时间,但其余是随机的,因此同一毫秒内生成的两个 v7 不会被确定性地排序。不要依赖其作平手比较(tie-breaking)。
• 以 VARCHAR(36) 存储。 可以工作,但相对于原生 16 字节 UUID / BINARY(16) 列,存储翻倍,连接变慢。请使用数据库的原生类型(Postgres 的 uuid、SQL Server 的 UNIQUEIDENTIFIER)。
• 要求特定版本的正则。 /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i 只匹配 v4。如果你后面开始发 v7,这条正则会默默拒绝合法 ID。

UUID v4 和 v7 有什么区别?

v4 除去版本和变体标记后有 122 位随机数,不含时间成分。v7 在前面嵌入 48 位 Unix 毫秒时间戳,其余填充随机位,因此时间相近的 v7 值在字典序中也排在相近位置。把 v7 用作数据库主键可以让 B-tree 插入集中在局部;只想要完全无序标识符时用 v4。

会产生重复的 UUID 吗?

实际上不会。v4 UUID 有 122 位随机数,十亿规模内两两相撞的概率约为 10^-18。要达到 50% 的碰撞概率,需要生成约 2.7 × 10^18 个 v4。把唯一性视为理所当然,不要再加去重检查。

v4 是加密强度的随机数吗?

本工具使用 crypto.randomUUID(),根据规范要求其必须来自加密强度 PRNG。用于会话 ID、幂等键及大多数安全令牌都够用。但它无法代替签名令牌或长 API 密钥,也不应该从 UUID 派生加密密钥。

UUID v7 已经是标准吗?

是的。UUID v7 在 RFC 9562(2024 年 5 月)中定义,该 RFC 取代了 RFC 4122,并在原版本之外正式确立了 v6、v7 和 v8。大多数现代语言都有 v7 实现——Postgres、MySQL、SQL Server 都可无需修改地接受 v7 作为 UUID 列。

二进制形式是什么样的,字节序(endianness)是否重要?

UUID 是 16 字节。标准文本形式按 8-4-4-4-12 的十六进制分组。按 RFC 9562,字节以网络(大端)顺序书写,因此 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 以字节 0x01 开头。Microsoft GUID 在内存中历来把前三组以小端存储——与 .NET 的二进制转储互操作时要当心。

你们会保存此工具生成的 UUID 吗?

不会。我们不会保存您在这里生成的 UUID。所有值仅显示在输出区域,刷新或关闭标签页即消失——什么都没有存下来,也不会对这些值收集任何遥测。欢迎在浏览器开发者工具中自行验证。