工作原理
UUID v4 是 122 位随机数据，另有 6 位保留用于标记版本与变体，渲染为五组共 32 个十六进制数字。它的优势在于生成完全不需要协调：两台从未通信的机器各自生成，碰撞概率也可以忽略。代价是取值完全随机，插入 B 树索引时写操作会散布到整棵树，批量导入一百万行会触碰一百万个不同的页面，在大表上这是可测量的吞吐问题。
UUID v7 正是为解决这一点而生：它在最高位放入 48 位毫秒时间戳，其后是随机数据。由于取值随时间递增，它们会追加到索引末尾而不是散布其中，写性能接近顺序整数，同时保留足够随机性使其不可猜测。代价是时间戳对任何持有该标识符的人可见，从而暴露记录创建时间以及大致的数据量——有时有用，有时是泄露。
ULID 用不同编码表达了同样的思路：48 位毫秒时间戳加 80 位随机数，以 Crockford Base32 表示。该编码大小写不敏感，并去掉了容易混淆的字母 I、L、O、U。结果是 26 个字符、可按字典序排序、放进 URL 或文件名无需转义。Nano ID 走的是相反路线：使用紧凑的 URL 安全字母表，默认 21 个字符、约 126 位熵，追求的是“仍然不会碰撞的最短标识符”。
MongoDB ObjectId 看着另类，但遵循同样的趋势。它是 12 个字节：4 字节 Unix 秒级时间戳、5 字节进程随机值、3 字节计数器。它按创建时间可排序，比 UUID 短，并且是针对特定数据库的索引行为设计的。密码则从可配置的字符集中生成，并给出以比特表示的熵值，这才是真正重要的数字——长度本身是很差的替代指标，因为从 26 个字母中取 16 位字符的密码，其熵远低于从 94 个可打印 ASCII 字符中取 11 位。
常见应用场景
- 为需要可排序、对索引友好的新表生成主键。
- 在分布式系统中生成关联 ID，用于跨服务追踪一次请求。
- 在没有任何中心计数器的情况下生成唯一的文件名或对象存储键。
- 生成不泄露记录信息的会话令牌或邀请令牌。
- 为需要大量真实标识符的测试夹具生成数据。
- 生成带明确熵值的高强度随机密码或 API 密钥。
最后更新: 2026-10-14