快速生成通用唯一标识符（UUID），可用于数据库主键、API密钥、会话ID等各类需要唯一标识的场景。
UUID（Universally Unique Identifier，通用唯一标识符）是一种128位的标识符，不依赖任何中央系统协调即可保证全球范围内的唯一性。它通常以8-4-4-4-12的十六进制格式表示，例如550e8400-e29b-41d4-a716-446655440000，无论在世界上哪台设备生成，重复的概率都低到可以忽略不计。常见的应用包括数据库主键、会话ID、文件命名、API访问令牌等。UUID有时也被称作GUID（Globally Unique Identifier），其规范由RFC 4122定义。
UUID标准共定义了5个版本，各自采用不同的生成逻辑。v1基于MAC地址与当前时间戳组合而成，能够保证生成顺序与时间一致，但由于会暴露设备MAC地址，存在一定的安全隐患。v4完全依靠随机数生成，具有极高的不可预测性，是目前使用最广泛的版本。v7是2024年才正式纳入标准的新版本，兼具时间戳排序能力，因此非常适合作为数据库索引字段。至于v2主要用于DCE安全场景，v3与v5则基于命名空间生成，应用范围较为特殊、有限。
UUID的用途十分广泛。在分布式系统中，各节点无需借助中央服务器协调，就能各自独立生成唯一ID，因此天然具备良好的横向扩展能力。在数据库设计中，用UUID替代传统的自增主键，可以有效避免多源数据合并时发生的ID冲突问题。在微服务架构里，UUID常被用来标记和追踪跨服务的调用链路。除此之外，它还广泛应用于防止文件上传时的重名冲突、生成一次性令牌、跟踪系统事件，以及关联分析日志数据等场景。
选择哪个UUID版本，取决于具体的业务需求。如果你需要保证生成顺序与时间对应，并且不介意MAC地址被间接暴露，可以选用v1，但要注意这会带来追踪生成设备位置的隐私风险。如果安全性是首要考量、且不关心生成顺序，v4通常是更稳妥的选择，因为它完全随机、无法被预测，也不会泄露任何设备相关信息。若你希望同时兼顾时间排序与安全性，则更推荐使用v7——它按时间戳排序，能带来更好的数据库写入与查询性能，同时减少索引碎片化问题。
UUID发生碰撞的概率低到近乎天文数字。以v4为例，其128位中有122位是随机生成的，理论组合数高达2^122（约5.3×10^36）种。即便以每秒生成10亿个UUID的速度持续运行，要达到50%的碰撞概率也需要大约85年时间。v1则通过60位时间戳与14位时钟序列来保证时间维度上的唯一性，再结合48位MAC地址保证空间维度上的唯一性。v7的设计更进一步，将48位Unix时间戳与74位随机数结合，同时兼顾了时间顺序性与唯一性两方面的需求。
将UUID作为数据库主键，能带来诸多好处：在分布式部署环境下，每个节点都能独立生成ID而无需依赖中央生成服务，扩展性极佳；数据合并迁移时不会产生ID冲突；即使ID出现在URL中被外部看到，也无法被按顺序猜测出下一个值，从安全角度更有保障。但这种方式也并非没有代价——UUID占用16字节存储空间，远大于普通整数类型（通常4到8字节），而且v4版本的随机性可能会拖慢B-tree索引的写入效率。若数据库性能是关键考量，改用按时间排序的v7版本，可以显著改善索引碎片化、提升整体查询性能。