UUID 生成器（v4 GUID）— speedor.net

UUID 究竟是什么

UUID 是 Universally Unique Identifier（通用唯一标识符）的简称，它是一个 128 位的值，用来给某样东西贴标签，而无需先向任何人请求许可。你也可能看到它被叫做 GUID，即 Globally Unique Identifier（全局唯一标识符），这只是微软在 Windows 和 .NET 世界里给同一概念起的名字。在几乎所有要紧的情形下，这两个词描述的是同一个 128 位数字，所以当同事说 GUID、你说 UUID 时，你们几乎总是在谈论一模一样的东西。

这 128 位通常写成 32 个十六进制数字，用连字符按 8-4-4-4-12 的模式分成五组。一个典型的值看起来像 123e4567-e89b-12d3-a456-426614174000。连字符本身没有任何含义；它们存在纯粹是为了让人能读这个值而不会看错位置。每个字符都是 0 到 f 的十六进制数字，这就是为什么 UUID 感觉比日常数字更密集，尽管它在底层只是一个非常大的整数。

各个版本，以及为什么 v4 胜出

该标准定义了几个版本，它们在如何填充这些位上有所不同。版本 1 是基于时间的：它把当前时间戳和机器的网络 MAC 地址编织在一起。这让 v1 的值可以按创建时间排序，但它也泄露了关于它们在何处、大致何时生成的信息，而这并不总是受欢迎的。版本 3 和 5 是基于名称的，它们对一个命名空间加一个名称做哈希，所以相同的输入总会得出相同的标识符。

版本 4 走的是完全不同的路线。它几乎是纯粹的随机。在这 128 位中，有六位被保留用来标记版本和变体，剩下 122 位用随机数据填充。没有时间戳，没有 MAC 地址，没有命名空间，只有噪声。这正是为什么大多数生成器，包括这一个，默认产生 v4。它不透露任何关于设备或创建时刻的信息，也不需要生成各方之间的任何协调。本页上的工具完全在你的浏览器中运行，所以随机值绝不离开你的机器。

碰撞到底有多不可能

一个合理的担忧是，两个随机的 UUID 有朝一日可能完全相同。有了 122 个随机位，v4 可能值的空间是 2 的 122 次方，大约是 5.3 后面跟着 36 个零。用人能理解的话说，你得每秒生成数十亿个 UUID，持续好几十年，单次出现重复的几率才会爬升到任何你能测量出来的程度。标准本身把发生冲突的几率描述为接近于零、可忽略不计。实际中团队把 v4 当作唯一的，然后继续干活，他们这么做是对的。

开发者在哪些地方会用到它们

因为唯一性不需要中央权威，UUID 在协调代价高昂或根本不可能的场合大放异彩。它们天然适合做数据库主键，尤其是当多个服务各自插入行、而你无法停下来向一个共享计数器索取下一个号码时。在分布式系统中，地球两端的两个节点可以在同一瞬间各自铸造标识符而绝不碰撞。它们还驱动着 API 幂等键，客户端给一个请求附上一个 UUID，这样在网络重试时服务器就能安全地忽略重复的请求。会话令牌、文件名、事件 ID 和消息键全都依赖同一个特性。

UUID 与自增 ID 的对比

经典的替代方案是自增整数：1、2、3，以此类推。顺序 ID 紧凑、天然有序、便于阅读，但它们有实打实的缺点。它们暴露了存在多少条记录，让外人能猜出相邻的值，而且它们迫使每次插入都经过单一计数器，当你对数据库分片或合并来自多个来源的数据时，这就成了瓶颈。UUID 解决了这些问题，它让任何一方都能独立生成一个键，且不透露任何关于数量或顺序的信息。代价是尺寸更大，以及索引中的局部性稍差一点。对于要横向扩展、或必须隐藏内部细节的系统，这个代价通常是值得付的。你可以通过我们的全部生成器合集探索这个以及类似的工具，或浏览更广的一套开发者工具，找到相关的构建模块。

常见问题