给数据生成一个唯一标识符，听起来是件小事，但在分布式系统里却暗藏难题：当多台机器、多个服务、甚至多个数据中心都要同时创建新记录时，谁来保证它们生成的 ID 不会撞车？传统做法是让数据库集中分配自增编号，可这需要协调，会成为瓶颈。UUID 提供了另一条思路——让任意系统都能独立生成一个几乎不可能重复的标识符，全程无需向任何中心请求。
集中分配 ID 的困境
最常见的 ID 方案是数据库自增编号：每插入一条记录，由数据库递增地分配下一个数字。它简单、紧凑、有序，但有一个根本前提——必须有一个集中的权威来保证不重复。当系统扩展到多个独立节点时，这个集中点要么成为性能瓶颈，要么需要复杂的协调机制。
更麻烦的是，很多场景下你希望在数据还没到达数据库之前就拥有它的 ID，比如客户端先生成、再上传。自增编号做不到这一点，因为编号要等数据库分配。
用概率取代协调
UUID 的核心思路是用概率换协调。它不去保证"绝对唯一"，而是让标识符的取值空间大到惊人——一个 128 位的数字，可能的取值多到难以想象。在如此巨大的空间里随机取值，两次取到相同值的概率小到可以忽略不计。
正因为重复的概率微乎其微，每个节点都可以放心地自行生成 UUID，而不必担心和别处撞车。协调被概率取代了：不是有人在背后保证不重复，而是空间大到几乎不可能重复。
128 位到底有多大
理解 UUID 为何可靠，关键在于体会那个数字空间的尺度。128 位能表示的不同取值数量，是一个天文级别的数字，远超日常直觉所能把握。即便全世界的系统持续不断地生成 UUID，要在这个空间里碰巧产生一次重复，所需的数量也大到不切实际。
正是这种近乎荒谬的巨大，让"靠随机取值避免重复"从一个听起来冒险的想法，变成了一个工程上完全可靠的方案。它不保证数学上的绝对唯一，但提供了实践中足够的唯一。
标准化的文本表示
UUID 通常以一种固定格式的文本呈现：用连字符分成几段的十六进制字符串。这种统一的表示让 UUID 可以在不同系统、不同语言、不同数据库之间无障碍地传递和识别。任何遵循标准的工具，都能解析和生成同样格式的 UUID。
这种标准化很重要——它意味着一个在某个服务里生成的 UUID，可以原样传给另一个完全不同的系统，对方依然能正确理解和存储。统一的格式是它能被广泛采用的基础之一。
不止随机：版本的差异
并非所有 UUID 都靠纯随机生成。UUID 有多个版本，采用不同的策略来填充那 128 位。有的几乎完全基于随机数，有的把时间信息编进去以便排序，有的则基于某个命名空间和名称做确定性计算。每种策略都针对不同的需求做了取舍。
了解存在多个版本很重要，因为它们的特性差别不小：有的更适合做数据库主键，有的适合在分布式系统里保持时间有序，有的能保证同样的输入永远得到同样的 UUID。选对版本，才能发挥它的长处。
独立生成带来的自由
UUID 最大的价值，在于它解耦了"生成 ID"和"中心权威"。客户端可以在离线时就生成 ID，多个服务可以并行创建记录，数据可以在写入数据库之前就带着自己的标识。这种自由极大地简化了分布式系统的设计。
它还让数据合并变得更容易：来自不同来源的记录，各自带着全局唯一的 UUID，合并时几乎不必担心 ID 冲突。这是集中式自增编号难以企及的灵活性。
代价与适用边界
当然，UUID 不是没有代价。它比自增编号长得多，占用更多存储空间；它通常没有自然的顺序，在某些数据库里用作主键时可能影响索引效率；它对人也不友好，难以记忆和口头传达。这些都是为了"无需协调的唯一性"而付出的代价。
所以选择 UUID，本质上是在做一笔权衡：用更大的体积和更弱的可读性，换取分布式环境下独立生成、几乎不重复的便利。当你的系统确实需要这种自由时，这笔交易非常划算；而在简单的单库场景里，自增编号也许依然是更朴素的选择。