实用工具2026-05-24Begin5 分钟阅读

UUID 生成器：在线生成唯一标识符完全指南

什么是 UUID

UUID（Universally Unique Identifier）是一种 128 位的唯一标识符，设计目标是在不需要中央协调的情况下生成全局唯一的 ID。UUID 的标准格式为：

550e8400-e29b-41d4-a716-446655440000

共 36 个字符（含 4 个连字符），分为 5 段，每段由 16 进制数字组成。

UUID 的版本

UUID v4（随机生成）

最常用的版本，完全由随机数生成。碰撞概率极低——生成 10 万亿个 UUID，碰撞概率仅为 50%。

格式：xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
      (4 = 版本号, y = 8/9/a/b)

适用场景：数据库主键、会话 ID、API 请求追踪

UUID v1（时间戳 + MAC）

基于当前时间戳和机器 MAC 地址生成。包含时间信息但暴露 MAC 地址，有隐私风险。

UUID v5（基于命名空间）

使用 SHA-1 哈希对命名空间 + 名称生成确定性 UUID。相同输入始终产生相同输出。

适用场景：需要可重现 ID 的场景（如 URL 的唯一标识）

NanoID：更短的替代方案

NanoID 是一种可配置长度的唯一 ID 生成器，默认使用 URL 友好的字符集（A-Za-z0-9_-），常和Lorem Ipsum 生成器一起用于生成测试数据：

NanoID (21位): V1StGXR8_Z5jdHi6B-myT

与 UUID v4 的对比：

特性	UUID v4	NanoID
长度	36 字符	可配置（默认 21）
字符集	十六进制	64 个 URL 友好字符
碰撞概率	2^-128	取决于长度和字符集
URL 友好	需要移除连字符	天然友好

ULID：带排序能力的唯一 ID

ULID（Universally Unique Lexicographically Sortable Identifier）结合了时间戳和随机数，支持按时间排序：

格式：01ARZ3NDEKTSV4RRFFQ69G5FAV (26字符, Crockford Base32)

特性	UUID v4	ULID
排序	无序	按时间有序
长度	36 字符	26 字符
可排序	❌	✅
时间信息	❌	✅（前 10 位是时间戳）

适用场景：需要按创建时间排序的主键、日志追踪

如何选择 ID 方案

场景	推荐方案
数据库主键	ULID（有序，索引友好）
会话/追踪 ID	UUID v4（标准、广泛支持）
短链接/邀请码	NanoID（短、URL 友好）
可重现 ID	UUID v5（确定性）
分布式系统	UUID v4 或 ULID（无需协调）

使用在线 UUID 生成器

ToolVault 工具匣的 UUID 生成器支持：

UUID v4：一键生成，复制即用
NanoID：可自定义长度和字符集
ULID：带时间戳的可排序 ID
批量生成：一次生成多个 ID

v7 为什么在吃掉数据库世界

v4 随机把插入散布在整个 B 树——每次插入都是随机页写入、缓存不命中。v7 把 48 位毫秒时间戳放在高位修复这个：键升序到达、插入打最右侧页、树保持热。重写入负载下实测是实质性的写放大削减。v7 在 2024 年定稿为 RFC 9562——「够稳定吗」的问题已终结。唯一注意：时间排序泄露创建时间——会话 token、URL 可见 ID 这类敏感场景 v4 的不透明仍是对的选择；内部主键 v7 现在是默认推荐。生成器两者都支持加 ULID（同思路、Crockford 编码 26 字符）供跨系统比较。

碰撞数学，不糊弄

v4 有 122 个随机位。生日界的答案：生成 2.7 万亿个 v4 才有十亿分之一的碰撞机会——不是不可能，但 2.7 万亿约等于单系统每秒一千个、连续跑一百年。现实风险不在算法：在重复生成 bug（VM 克隆后两台机器同种子 PRNG——1999 年 Kerberos 事故正是如此）和没有唯一约束的数据库里的复制粘贴。UUID 永不碰撞也保留唯一索引——索引是对真实失败模式的廉价保险。

存储格式税

UUID 按文本存是 36 字节加每行开销；原生 uuid 类型（Postgres）或 16 字节 binary 是 16。亿行表上这个差是 GB 级和可测的索引深度。MySQL 无原生 UUID 类型（BINARY(16) 加边界转换 UUID_TO_BIN/BIN_TO_UUID；swap 标志顺带做时间局部性）。应用侧 Java 的 UUID 和 .NET 的 Guid 本来就是 128 位值——序列化成字符串进数据库等于白交格式税。

实际踩坑记录

前端生成 + 后端校验不一致：前端生成 v4，后端按 v1 格式校验（检查版本位），导致批量拒绝。统一约定：要么全 v4，要么全 v7，并在 schema 层校验版本位。
大小写敏感：标准 UUID 是小写，但某些系统接受大写后混存。比较前统一转小写，或存数据库时用 COLLATE 强制。
连字符丢失：某些 API 返回无连字符的 32 位 hex，代码里按有连字符解析就崩。解析时先 normalize：s.replace(/-/g, '').toLowerCase()，再按格式重组。

实现注记 / Implementer's note

本站 UUID 生成器用 crypto.getRandomValues 生成 128 位随机数，再按 RFC 9562 格式化。v7 模式把当前毫秒时间戳写入高 48 位，剩余 74 位随机；ULID 用 Crockford Base32 编码。批量生成时循环调 getRandomValues（每次 128 位），不缓存种子，避免 VM 克隆后同种子的经典事故。

FAQ

UUID 碰撞概率有多大？

UUID v4 的空间为 2^128 ≈ 3.4×10^38。生成 10 亿个 UUID，碰撞概率约为 10^-18（几乎为零）。在实际应用中，UUID 碰撞从未被确认发生过。

NanoID 比 UUID 安全吗？

取决于长度和字符集。21 位 NanoID（64 字符集）的熵约为 126 bit，与 UUID v4（128 bit）接近。选择足够长的 NanoID 即可。

为什么 ULID 比 UUID 适合做数据库主键？

数据库索引（如 B+Tree）对有序插入更高效。UUID v4 完全随机，每次插入都可能导致页分裂。ULID 按时间排序，插入模式更接近顺序写，性能更好。

本文由 ToolVault 工具匣提供。首页汇集了更多浏览器本地工具。