生成UUID
私密处理——您的文件绝不会被存储
选择哪个版本？
您的0个UUID将显示在这里。
使用方法
选择版本
必须无法猜测的用途选v4，数据库主键选v7。两者的区别在页面上有说明，而不是默认您已知道。
选择数量
一个，或一次最多10,000个，可选格式——大写、加花括号、去掉连字符，或生成可直接用于代码的带引号列表。
复制结果
全部复制，或下载为文本文件。
v4还是v7，以及为什么这在数据库中很重要
UUID是128位的数值，写成32个十六进制数字，按熟悉的8-4-4-4-12分组。其中六位用来标明版本和变体，于是v4中剩下122个随机位——多到即使每秒生成十亿个、持续一百年，出现重复的可能性也微乎其微。这正是它全部的魅力所在：两个从未通信过的系统可以各自生成标识符，并放心地认为它们永远不会冲突。
要做到这一点，随机性必须是真实的，而这里的随机性来自密码学安全随机源，而不是普通的随机数生成器。当标识符被用作访问凭证时——比如密码重置链接、无法猜到的分享网址——这个区别就很重要，因为可预测的生成器会让人根据之前的值推算出下一个值。使用密码学安全随机源，就没有什么可以预测的。
v7之所以存在，是因为v4用作数据库主键时表现很差。它把48位毫秒级时间戳放在最前面，其余部分用随机数填充，所以依次生成的UUID会按创建顺序排列。这听起来只是表面功夫，其实不然：随机主键会把每次插入分散到整个索引中，每次写入都会触及不同的页，缓存也就不再起作用；而按时间排序的主键只会追加到一端。在大表上，插入吞吐量的差异相当可观，这也是v7被纳入标准的原因。
这个取舍是真实存在的，值得权衡。任何人看到v7 UUID，都能知道它大致的创建时间，精确到毫秒；一连串v7 UUID还会暴露您创建记录的速度。对内部主键来说这没问题。但对于暴露在URL中的标识符——订单号、文档链接、用户ID——这就是一个v4所没有的小小信息泄露。如果两方面都要顾及，主键用v7，公开的内容用v4。
如果您需要的是别的
在使用它们的地方生成。每种数据库和编程语言都内置了这个功能——PostgreSQL的gen_random_uuid()、MySQL的UUID()、JavaScript的crypto.randomUUID()、Python的uuid.uuid4()——在浏览器里批量生成再粘贴到代码中，用于测试夹具或测试没问题，用于实际运行的程序就不对了。
如果使用v7是为了可排序的主键，还有一些值得了解的替代方案。ULID用26个更短且不区分大小写的字符实现同样的思路；Snowflake标识符只占64位，与UUID的128位相比，索引大小减半。而在许多数据库中，普通的自增整数仍然比它们都更快、更小——只有当标识符必须在多个地方同时生成时，UUID才值得付出这些代价，否则并不值得。
常见问题
v4还是v7——我该用哪个？
如果是数据库主键，用v7。如果必须无法猜测——密码重置链接、邀请码、会话标识符——用v4。需要做的决定就这么多，而大多数人根本不知道这里还有选择，因为几乎所有生成器都只提供v4。
为什么v4不适合做数据库主键？
因为它完全随机，而数据库索引是有序的。新的随机主键会落在索引中的随机位置，所以每次插入都会触及不同的页，缓存不再起作用，索引也会产生碎片并不断膨胀。在繁忙的大表上，这会造成可测量的性能下降，而且随时间推移越来越严重。这并非理论上的担忧——正因如此，Postgres和MySQL的文档现在都专门讨论了这个问题。
什么是UUID v7？
一种前48位是毫秒级时间戳、后面跟着随机数的UUID。它依然全局唯一，依然是128位，但因为时间在最前面，v7 UUID会按创建顺序排列。新主键追加到索引末尾，而不是分散在索引各处，这与自增整数的行为完全一样——同时又具备UUID的唯一性。它于2024年在RFC 9562中被标准化，是目前新建数据表的推荐选择。
这里生成的v7 UUID真的能正确排序吗？
能，即使在同一毫秒内也能，而这正是大多数实现出错的地方。时间戳只精确到毫秒，所以在循环中生成一千个ID往往在一毫秒内就完成了——如果低位纯粹随机，这一千个ID“不会”按生成顺序排列。本生成器使用RFC 9562中描述的单调计数器，所以每一批都严格递增，次次如此。生成一千个再排序，它们会按创建顺序排列。
v7 UUID可以公开暴露吗？
可以，但要记住一点：按设计，它会暴露自己的创建时间，精确到毫秒。对数据库主键来说，这通常无害，甚至有用。但如果创建时间本身是敏感信息，或者您需要标识符无法被猜到，请使用v4——v7仍有74个随机位，已经相当多了，但任何拿到这个ID的人都能直接读出其中的时间戳。
这些UUID的随机性足够安全吗？
足够。随机性来自`crypto.getRandomValues`，即浏览器的密码学安全随机数生成器，绝不使用`Math.random`。这个区别曾导致过真实的漏洞：`Math.random`速度快但可预测，基于它生成的会话令牌在现实中就曾被猜中。v4 UUID有122个随机位，足以让冲突在实际中无需担心。
UUID是在我的设备上生成的吗？
是的，完全在您的设备上，而对标识符来说这很重要。从别人的服务器获取的UUID，就是别人已经见过的UUID——如果您要生成的是密钥，这就失去了意义。这些UUID从不离开您的浏览器。页面加载完成后，关掉Wi-Fi，它照样完全正常工作。这是您亲自验证隐私承诺的最简单方法，而不必只听我们的一面之词。
什么是Nil UUID？
全部为零：00000000-0000-0000-0000-000000000000。它是一个合法的保留UUID，在无法使用null的地方表示“无”或“未设置”。与之相对的是全部为f的Max UUID，有时用作排序的哨兵值。这里两者都提供，因为偶尔会用到，而手动输入又很容易出错。
小贴士： v4 UUID来自浏览器的密码学安全随机源，而不是Math.random，因此可以放心用作标识符。v7内嵌毫秒级时间戳，这正是它便于排序的原因——但也意味着它会暴露大致的创建时间。在这一点很重要的场景中，请不要使用v7。
把这个工具放到您的网站上
博客、课程页面或帮助文章均可免费使用。粘贴一段代码，访客就能直接在您的页面上使用。