UUID / ULID / Token 标识符指南
UUID、ULID 与随机 Token 是开发者最常用的三类标识符。本页对比它们的格式、长度、是否可排序以及典型适用场景，帮助你在数据库主键、API Key 和会话 ID 之间做出合适选择。
| 标识符 | 格式 | 长度 / 熵 | 可排序 | 最佳场景 |
|---|---|---|---|---|
| UUID v4 | xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx | 122 位随机 + 6 位版本/变体 | 否（完全随机） | 数据库主键、分布式 ID、隐私场景 |
| UUID v7 | 时间戳(48bit) + 随机(74bit) | 128 位 | 是（按时间单调递增） | 需要可排序主键的新系统 |
| ULID | TTTTTTTTTTRRRRRRRRRRRRRRRR（Crockford Base32） | 48 位时间戳 + 80 位随机 | 是（按生成时间字典序） | URL 安全、可排序、人类可读标识符 |
| 随机 Token | 十六进制 / Base64 / Base62 字符串 | 按需（常见 128–256 位） | 否 | API Key、Session、激活码、邀请码 |
常见问题
UUID 会重复吗？
UUID v4 的冲突概率极低：理论上需要生成约 10^18 个 122 位随机 UUID 才可能出现一次碰撞，远超常规业务规模。UUID v7 和 ULID additionally 引入时间前缀，同一毫秒内生成的 ID 仍有 80 位随机空间，冲突风险同样可忽略。
UUID v4 和 ULID 该怎么选？
需要可排序、URL 更短、可读性更好 → 选 ULID。需要最广泛兼容、隐私性最强（完全看不出生成时间）→ 选 UUID v4。新项目若数据库主键需要按时间排序，可直接考虑 UUID v7。
Token 应该用什么字符集？
十六进制最简单、最易读；Base64 最短但含 +/= 可能污染 URL；Base62 去掉特殊符号，兼顾长度与 URL 安全；Base58 进一步排除易混淆字符（0/O、I/l），适合手动输入场景。
API Key 用 UUID 还是随机 Token？
API Key 建议用加密安全随机 Token（长度至少 128 位），不要直接用 UUID。UUID 主要设计为唯一标识，虽然熵足够，但专用 Token 在长度、字符集、前缀标识（如 sk_live_xxx）上更灵活，也更容易做权限前缀区分。