很多人以为 UUID 只有一种，随手生成一个用就是了。其实 UUID 有多个版本，它们填充那 128 位的方式各不相同，因而在随机性、可排序性、确定性等方面有着明显的取舍。选错版本，可能让你在数据库性能、数据可预测性或隐私上吃亏。了解各版本的特点，并按实际需求来选，才能真正用好 UUID。

为什么会有多个版本

所有 UUID 都是 128 位，但这 128 位可以用不同策略来填充：可以几乎全靠随机数，可以把时间戳编进去，可以基于机器信息，也可以对某个名称做确定性的哈希。每种策略服务于不同的目标，于是就有了不同的版本号。

理解这一点，就不会再把 UUID 当成铁板一块。版本之间的差异，恰恰是你为不同场景挑选合适方案的依据。

基于随机数的版本

最常见的一类 UUID 几乎完全基于随机数生成。它的优点是简单、无需任何外部信息、不泄露生成时间或机器细节，唯一性靠巨大的随机空间保证。对大多数"只要一个全局唯一标识"的需求，它都是稳妥的默认选择。

它的短板在于完全没有顺序。两个先后生成的随机 UUID，在排序上毫无关联。当它被用作数据库主键时，这种无序可能让插入分散在索引各处，影响写入效率。这正是其他版本试图改进的地方。

把时间编进去的有序版本

有一类较新的 UUID 把时间信息放在前面，使得生成时间越晚的 UUID，数值上也越大。这样一来，UUID 就天然带上了大致的时间顺序，既保留了无需协调的唯一性，又获得了可排序的好处。

这种有序性在数据库里尤其有价值：用它做主键时，新记录的 ID 大致递增，插入更集中，对索引更友好。如果你既想要 UUID 的分布式优势，又在意数据库性能和时间排序，这类版本往往是更好的选择。

确定性的命名版本

还有一类 UUID 不靠随机，而是基于一个命名空间和一个名称，通过哈希计算得出。它的关键特性是确定性：相同的输入永远产生相同的 UUID。这在你需要"由某个已知值稳定地推导出一个标识符"时非常有用。

比如，要为同一个资源在不同系统里生成一致的标识，或是想避免对同一输入重复创建不同 ID，这类确定性版本就派上用场。它的取舍是：既然输入决定输出，就要确保输入本身不会意外重复。

排序与索引的考量

选版本时，数据库行为是个绕不开的因素。随机 UUID 的无序会让基于它的索引插入变得分散，在大量写入时可能拖慢性能并增大索引体积。有序 UUID 则因为大致递增，能让插入更连续，缓解这个问题。

如果你的 UUID 主要用作高频写入表的主键，可排序版本通常更合适；如果它只是个偶尔生成的标识，随机版本的简单就足够。把使用模式想清楚，再决定要不要为排序性买单。

隐私与信息泄露

不同版本暴露的信息也不同。把时间编进去的版本，会让人从 UUID 中推断出它的生成时间；某些历史版本还可能包含与机器相关的信息。如果你的标识会暴露给外部，又不希望泄露这些细节，就要谨慎选择。

纯随机版本在这方面最"沉默"，它几乎不透露任何关于生成环境的信息。当隐私是顾虑时，这种不携带额外信息的特性反而是优点。选版本时，别忘了把"它会暴露什么"也纳入考量。

按需求而非习惯来选

归根结底，没有哪个 UUID 版本在所有维度上都最优。随机版本胜在简单和不泄露信息，有序版本胜在数据库友好和时间排序，确定性版本胜在可由输入复现。每一种都是为某类需求量身定做的取舍。

选择时，先问自己几个问题：它会被频繁用作主键吗？需要按时间排序吗？需要由已知输入稳定推导吗？会暴露给外部吗？把这些需求理清，对应的版本自然就浮现了。按需求选，而不是随手抓一个默认值，才是用好 UUID 的关键。