UUID v4 生成器

什么是 UUID？何时应该生成它？

使用场景

1. 01

   多服务并发写入的数据库表主键——使用 UUID 可免去中心化序列协调。

2. 02

   分布式日志中的请求 ID——为每个请求附加 UUID，便于在微服务间追踪用户调用链路。

3. 03

   支付 API 的幂等键——使用客户端生成的 UUID 可避免重试时重复扣款。

4. 04

   S3 上传文件标识符——文件名中加入 UUID 可避免冲突，且不暴露任何内部结构信息。

5. 05

   邀请码或密码重置令牌——UUID v4 的随机性足以胜任这类场景的安全令牌。

计算原理

常见问题

我该使用哪个 UUID 版本？

现代推荐使用 UUID v7（RFC 9562）——它兼具时间顺序（利于数据库索引）和足够的随机性以保证唯一性。在不关心顺序的场景中，UUID v4 依然适用。UUID v1 在如今很少是最佳选择——它会暴露 MAC 和生成时间。UUID v3/v5 是确定性的（命名空间 + 名称的哈希值）——适用于从相同输入生成相同 UUID。

UUID 会发生碰撞吗？

理论上有可能，实践中几乎不可能。在整个人类历史中，两个随机生成的 v4 UUID 发生碰撞的概率约为 2^-122 量级——相当于连续多次中头奖。对于 UUID v1 和 v7（使用时间戳），概率更低，因为时间戳额外提供了时间维度的唯一性。

UUID 用作身份验证令牌是否安全？

具备 128 位随机性的 UUID v4 对于短期令牌（邀请码、密码重置）足够安全——熵约等于 122 个随机比特。对于长期令牌（API key、JWT），还需配合定期轮换、过期机制和撤销策略。切勿使用 UUID v1 或 v3 作为令牌——它们可被预测或推导。

为什么数据库中的 UUID 可能变慢？

因为 UUID v4 是完全随机的——在 B-tree 索引中插入会引发碎片化和缓存未命中。UUID v7（按时间戳排序）解决了这一问题：插入变为索引上的追加写入，性能可媲美自增整数。Postgres 在较新版本中通过 uuidv7() 提供原生支持。

UUID 可以缩短用于 URL 吗？

可以，将 128 位用 Base62 或 Base64URL 编码即可（不要用标准 Base64，其字符在 URL 中存在问题）。NanoID 和 Sqids 等工具默认就是这样做的，可生成 21 个字符且熵相同的 ID。但如果你已有生成好的 UUID，保留 36 字符的规范格式可移植性更好。

UUID v4 能离线工作吗？

可以——生成 UUID v4 无需中心协调或联网，只需要一个加密安全的随机数生成器。这也是 UUID 在分布式系统中颇具价值的原因：离线客户端可生成有效 ID 并稍后同步，而不必担心碰撞风险。

相关工具

• JSON 格式化工具

  组织载荷结构
• Hash 生成器

  确定性指纹
• Slug 生成器

  友好的 URL

官方资料

Tabelas, leis e referências consultadas para fundamentar esta ferramenta.

1. 01

   国际标准·RFC 4122 (2005)·IETF · 互联网工程任务组

   RFC 4122 — 通用唯一标识符 (UUID) URN 命名空间

   UUID 标识符规范（版本 1、3、4 和 5），规定 36 字符规范格式以及保证全局唯一性的生成规则。

   Consultar fonte oficial
2. 02

   国际标准·RFC 9562 (2024)·IETF · 互联网工程任务组

   RFC 9562 — 通用唯一标识符 (UUIDs)

   UUID 标准的更新版本，新增版本 6、7、8——按时间排序，并针对数据库与现代分布式系统的使用场景进行了优化。

   Consultar fonte oficial