UUID 生成器 - LitekitHub

UUID 生成器完整指南：各版本区别、使用场景与最佳实践

UUID（通用唯一标识符）是软件开发中最常用的 ID 格式之一。本文将详细介绍 UUID 的结构、各个版本的区别（v1、v3、v4、v5、v7、NIL），并讲解如何借助在线 UUID 生成器快速批量生成符合 RFC 9562 标准的唯一标识符。

UUID（Universally Unique Identifier，通用唯一标识符），也称 GUID（全局唯一标识符），是一种由 128 位（32 个十六进制字符）组成的标准化 ID，格式如下：

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx（8-4-4-4-12）

UUID 的设计目标是在不依赖中央注册机构的情况下，在全球范围内生成唯一 ID。理论上，随机生成的 UUID v4 碰撞概率约为 1/3×10³⁸，在工程实践中可视为绝对唯一。

UUID 标准目前共定义了 7 个版本（RFC 9562），本工具支持全部主流版本：

版本	生成算法	特点	典型场景
NIL	全零	固定值 `00000000-0000-0000-0000-000000000000`	空值占位、初始状态标记
v1	时间戳 + MAC 地址	包含生成时刻，可从 UUID 反推时间；隐含设备信息（MAC）	需要时间排序的日志系统、分布式追踪
v3	MD5 + 命名空间	确定性输出：相同命名空间 + 名称 → 相同 UUID	URL 指纹、幂等 ID 生成
v4	纯随机	最常用，无信息泄露，碰撞概率极低	数据库主键、用户 ID、会话 ID
v5	SHA-1 + 命名空间	确定性，比 v3 更安全（SHA-1 vs MD5）	资源命名、内容寻址，需要可重现 UUID 的场景
v7	Unix 毫秒时间戳 + 随机	时间有序，天然排序友好；比 v1 更现代、信息更少	现代数据库主键（替代 v4），B-tree 索引性能更优

💡 选版本速查：不知道用哪个？
新项目数据库主键 → v7（时间有序，索引友好）
通用随机 ID → v4（最简单，最广泛支持）
需要可重现的确定性 ID → v5（更安全）或 v3（更快）

所有操作均在浏览器本地完成，不会上传任何数据。

ID 方案	长度	有序性	唯一性保障	适用场景
UUID v4	36 字符	无序	概率唯一（极高）	分布式系统通用 ID
UUID v7	36 字符	时间有序	概率唯一（极高）	数据库主键，索引友好
自增整数 ID	1–20 字符	严格有序	单库唯一	单体应用、小规模系统
Snowflake ID	18–19 字符	时间有序	需配置机器 ID	大规模分布式系统（微博、推特等）
随机 Token	自定义	无序	取决于长度和字符集	API 密钥、会话令牌、验证码

传统的 UUID v4 是纯随机的，插入数据库时会导致 B-tree 索引页频繁分裂，在高写入场景下性能明显下降。UUID v7 将 Unix 毫秒时间戳 放在高位，使 ID 具有时间有序性，新生成的 UUID 总是排在旧 UUID 之后，大幅减少 B-tree 分裂，显著提升写入性能。

MySQL、PostgreSQL 等主流数据库均已验证，在同等场景下，使用时间有序 UUID 作主键的写入性能比 v4 提升 30%–60%。 PostgreSQL 17 更是内置了 gen_random_uuid()（v4）并推荐迁移到 v7 兼容方案。

理论上 UUID v4 可能重复，但概率约为 1/(3×10³⁸)—— 相当于每秒生成 10 亿个 UUID、连续生成 850 万年，才有约 50% 的概率遇到一次碰撞。在实际工程中，这个概率可以完全忽略不计。

是的。v3 和 v5 是确定性 UUID——相同的命名空间 + 相同的名称字符串，无论何时、何地运行，都会生成完全相同的 UUID。这一特性让它们适用于需要「相同输入对应相同 ID」的场景，如资源 URL 指纹或配置文件哈希。

本质上是的。GUID（Globally Unique Identifier）是微软对 UUID 标准的实现叫法，格式与 UUID 完全相同，通常带有大括号 {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}。在跨平台开发中，两者可以互换使用。

各语言的标准做法：