UUID 生成器
生成随机 UUID——v4 版本适合通用场合,v7 版本适合需要在数据库中高效索引的、按时间排序的标识符。一次生成一个,或一次生成一千个,全部在本地完成。
- 文件永不离开你的设备
- 免费，无需注册
- 无水印
- 加载后可离线使用
如何UUID 生成器
- 1
选择一个版本
v4 适合通用随机 ID,v7 适合会作为数据库主键的 ID。
- 2
设置生成数量
一次生成从一个到一千个不等。
- 3
复制或下载
把列表复制到剪贴板,或下载为文本文件。
UUID 真正解决的是什么问题
UUID 是一个 128 位的标识符,设计成可以由任意数量的独立系统在任意时间各自独立生成,不需要任何中央协调机构来分配下一个可用的编号,同时依然拥有压倒性的统计保证,确保生成的值永远不会发生碰撞。这和一个自增整数 ID 有本质上的不同,后者需要一个单一的数据库来追踪并按顺序分配下一个编号——一个 UUID 可以在一部没有网络连接的手机上生成,可以在一个无服务器函数里生成,也可以在一千个并行的微服务实例之间同时生成,彼此完全不需要任何协调,因为这个数字空间的规模之大,让意外碰撞的概率低到天文数字级别,无论独立生成了多少个都是如此。
为什么 v4 和 v7 都是"随机"的,却解决着不同的问题
UUID 第 4 版几乎把全部 128 比特都填满密码学随机数据,这让每一个生成的值完全不可预测,也完全看不出它是什么时候生成的,或者相对于其他任何一个 v4 UUID 的生成顺序如何——这正是像安全令牌这类场景所需要的属性,在这种场景下,可预测性本身就是一个漏洞。UUID 第 7 版,在 2024 年通过 RFC 9562 才刚刚标准化,刻意牺牲了一部分这种不透明性:它把一个毫秒精度的时间戳放在前导比特里,所以一个后生成的 v7 UUID,排序总是排在先生成的后面,而剩余的比特依然保持随机,和 v4 一样不可猜测。这两者不是一种"谁更好"的竞争关系——它们把同样的底层随机性,按照排序性和统一不可预测性中哪一个对具体使用场景真正重要,交换成了不同的属性。
为什么使用随机主键的数据库会随着规模增长而变慢
支撑一个主键的数据库索引,通常存储为一棵 B 树,这种结构在新值被插入到现有排序顺序的末尾或附近时表现最好——这正是传统自增整数主键的行为方式。而一个 v4 UUID 主键,由于是均匀随机的,每一次插入都会落在这个排序结构里一个实际上随机的位置,这迫使数据库反复拆分和重新平衡散落在整棵树各处的索引页,而不是简单地追加到末尾。在小规模下,这种开销是察觉不到的;但在规模变大、有数百万行数据时,它会变成一个真实的、可测量的索引碎片化和写入变慢的来源——这正是 UUID v7 的前导时间戳被专门标准化来解决的问题,因为它能让一个 UUID 在保持唯一、不可猜测的同时,依然按大致的顺序插入。
常见问题
UUID v4 和 v7 有什么区别?
v4 完全是随机的。v7 会把一个毫秒级时间戳放进它的前导比特里,所以后生成的 ID 排序会排在先生成的后面。两者在实际使用中都同样不可预测;v7 只是恰好同时具备了有序性。
数据库主键应该用哪一个?
用 v7。随机的 v4 主键会把插入操作分散到整个 B 树索引的各个位置,导致索引碎片化,在规模变大后显著拖慢写入速度。v7 主键会按顺序追加,所以插入操作能保持连续——这正是 v7 在 2024 年被标准化的原因。
两个 UUID 有可能相同吗?
在数学上可能,但实际上不会。一个 v4 UUID 有 122 个随机比特;你需要生成大约 2.7 × 10^18 个才会让碰撞变得有可能发生。作为对比,这个数字比地球上所有沙粒的数量还要多。
这些 UUID 生成得安全吗?
安全。它们使用的是 `crypto.getRandomValues`,也就是你操作系统的密码学随机源,而不是 `Math.random`。如果一个 UUID 会被用作某种能力令牌——一个分享链接、一个取消订阅的 URL、一个密码重置密钥——这一点就很重要。
UUID 和 GUID 是同一个东西吗?
是的。GUID 是微软对同一种 128 位标识符的叫法。你会遇到的唯一区别是格式:微软的工具经常会给它加上花括号并使用大写,这两种格式这个工具都能生成。