所有生成操作均通过 Web Crypto API 在您的浏览器本地完成。任何 ID 或文本均不会发送至我们的服务器。
什么是 UUID？
UUID（通用唯一标识符）是 RFC 4122 定义的 128 位标签。v4 版本有超过 5 × 10³⁶ 种可能的值，生成两个相同 UUID 的概率极其微小。UUID 使分布式系统无需中央计数器或协调器即可创建唯一标识符——用于数据库行、API 资源、会话令牌等。
UUID v4 vs UUID v1 vs ULID vs NanoID
根据您的使用场景选择合适的标识符：
UUID v4（128 位随机）
完全随机。最广泛使用的格式，被所有现代数据库和编程语言原生支持。不含时间信息。使用 crypto.randomUUID() 生成。
UUID v1（基于时间戳）
已弃用
编码时间戳以支持时间排序。新系统已不推荐使用——原始规范会暴露 MAC 地址，存在隐私问题。如需可排序性，请使用 ULID。
ULID（字典序可排序）
按创建时间字典序排序——非常适合作为 Prisma、Drizzle 或任何 ORM 的数据库主键。26 个 Crockford Base32 字符，URL 安全，不区分大小写。
NanoID（紧凑型 URL 安全 ID）
仅 21 个字符（UUID 为 36 个），URL 安全字母表（A-Za-z0-9_-）。长度可配置。非常适合 URL 短链、短令牌和生成的标识符。
何时使用各类标识符
选择正确 ID 格式的实用指南：
UUID v4 → 数据库主键
在 PostgreSQL（uuid 类型）、MySQL（CHAR(36)）或任何原生支持 UUID 的数据库中使用 UUID v4 作为主键。所有主流 ORM 均支持。
UUID v1 → 按时间排序的日志文件
旧系统需要带内嵌时间戳的 ID 来命名日志文件或对事件排序。新项目请优先选择 ULID。
ULID → 与 ORM 配合使用的可排序主键
当您需要按创建时间排序的主键而无需单独的时间戳列时，请使用 ULID。与 Prisma、Drizzle ORM 和 TypeORM 原生兼容。
NanoID → URL 短链和紧凑令牌
在 URL 短链、短期令牌以及任何需要紧凑性和 URL 安全性的场景中使用 NanoID。调整长度以平衡碰撞概率和可读性。
如何通过 4 个步骤生成 UUID
-
选择标识符类型
从下拉菜单中选择 UUID v4（随机）、UUID v1（基于时间戳）、ULID 或 NanoID——每种格式适用于不同场景。 -
设置选项
选择要生成的数量（一次最多 100 个），切换大小写，并按需调整 NanoID 的长度。 -
批量生成
点击“生成”即可在浏览器中即时创建整批标识符——随时点击“重新生成”获取新的一批。 -
复制结果
使用“全部复制”将所有标识符复制到剪贴板，或在输出框中选择单独的行。
常见问题
UUID 是 128 位标识符，编码为带连字符的 36 个十六进制字符。ULID 同样是 128 位，但编码为 26 个 Crockford Base32 字符，并可按创建时间字典序排序。ULID 是 UUID v1 的现代替代方案，避免了 MAC 地址暴露问题。
理论上可以，但概率极其微小。UUID v4 有 122 位随机性，产生约 5.3 × 10³⁶ 个可能值。要有 50% 的碰撞概率，需要生成约 2.7 × 10¹⁸ 个 UUID——远超任何实际系统的需求。
是的。UUID v4 在分布式系统中被广泛用作主键。与顺序整数相比，主要的权衡是 B 树索引碎片化问题。如果有序插入很重要，可以考虑使用 ULID，它按时间顺序排序，可以减少碎片化。
NanoID 生成更短的 ID（默认 21 个字符，而 UUID 为 36 个），使用 URL 安全字母表。长度可配置：较短的 ID 碰撞概率更高，较长的 ID 更安全。NanoID 非常适合 URL、短链和紧凑令牌等 UUID 的 36 字符格式过长的场景。