免费在线 UUID / ULID / NanoID 生成器

在浏览器中即时生成UUID v4、UUID v1、ULID和NanoID — 一次最多100个。完全本地处理，无数据发送至服务器。

ID 类型

数量

大小写

小写大写

生成的 ID

所有生成操作均通过 Web Crypto API 在您的浏览器本地完成。任何 ID 或文本均不会发送至我们的服务器。

什么是 UUID？

UUID（通用唯一标识符）是 RFC 4122 定义的 128 位标签。v4 版本有超过 5 × 10³⁶ 种可能的值，生成两个相同 UUID 的概率极其微小。UUID 使分布式系统无需中央计数器或协调器即可创建唯一标识符——用于数据库行、API 资源、会话令牌等。

根据您的使用场景选择合适的标识符：

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。调整长度以平衡碰撞概率和可读性。

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 字符格式过长的场景。