UUID 生成器怎么用
- 选择生成版本 4得到完全随机的 UUID，或选生成版本 7得到按生成时间排序的 UUID。
- 设置数量（最多 1,000 个）和格式：带连字符的小写、去掉连字符的 32 位、Windows 和 .NET 习惯的 {花括号} 写法，或 URN 形式（
urn:uuid:…）。系统要求大写时勾选大写字母。 - 点击复制复制整个列表（每行一个），或再点生成换一批。
- 要检查手头的 UUID，选择检查或校验 UUID 并粘贴进去。结果会显示格式是否正确、版本和变体；对版本 1、6、7 的 UUID，还会显示它的生成日期和时间。
UUID 是什么
UUID（通用唯一识别码，微软的软件里叫 GUID）是一个 128 位的数，写成 32 个十六进制数字，按 8-4-4-4-12 分成五组。任何人都可以自己生成，不需要向中心机构申请，而两个 UUID 撞上的概率小到可以忽略，所以数据库、接口、文件格式和操作系统都拿它当主键或标识。现行标准是 2024 年 5 月发布的 RFC 9562，它取代了 RFC 4122。
每个 UUID 有两处是固定的：第 13 位是版本号，说明其余部分是怎么来的；第 17 位携带变体，按 RFC 布局时是 8、9、a 或 b。所以所有版本 4 的 UUID 都长成 xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx 的样子，其中 y 是 8、9、a 或 b。
| 版本 | 组成方式 | 能否按时间排序 |
|---|---|---|
| 1 | 自 1582 年起以 100 纳秒为单位的时间、时钟序列和节点 ID（通常是 MAC 地址） | 否 |
| 3 和 5 | 命名空间加名称的 MD5 或 SHA-1 哈希：同一个名称总得到同一个 UUID | 否 |
| 4 | 122 个随机位 | 否 |
| 6 | 版本 1 的字段，重新排列让时间在前 | 是 |
| 7 | 48 位 Unix 毫秒时间，加 74 个随机位 | 是 |
| 8 | 生成软件自己决定的布局 | — |
选 v4 还是 v7？
版本 4 是传统选择：完全随机，看不出它是何时、何地生成的。它的弱点在数据库索引。MySQL 的 InnoDB 按主键聚簇存储数据，随机主键会让每次插入落在 B+ 树的不同位置，频繁页分裂，数据量一大写入就变慢、表也更碎。版本 7 以当前时间开头，新行总是追加在索引末尾，效果接近自增 ID，同时又能在多台从不通信的服务器上各自生成而不冲突。RFC 9562 建议新系统在需要按时间排序时使用版本 7。
代价是：任何看到版本 7 UUID 的人都能读出它的生成时间，精确到毫秒。对大多数记录没有影响，但如果生成时间本身需要保密——比如公开链接里不应暴露账号是何时注册的——请用版本 4。在同一毫秒内，本生成器把 74 个随机位当作计数器，每次增加一个随机步长（RFC 9562 §6.2 方法 2），所以一次生成 1,000 个也严格按顺序排列，而且仍然无法猜测。
国内很多后端用雪花算法（Snowflake）生成 64 位整数 ID，它同样按时间递增，只占 8 字节，但需要给每台机器分配编号。UUID v7 不需要任何协调，代价是 16 字节。另外要注意，雪花 ID 超过 253，传给前端 JavaScript 时会被四舍五入，通常要转成字符串；UUID 本来就是字符串，没有这个问题。
为什么没有版本 1 选项
版本 1 的 UUID 包含生成者网卡的 MAC 地址和精确时间，这被证明是隐私隐患：1999 年，微软 Office 写进文档的这类标识帮助追查到了 Melissa 病毒的作者。网页本来也读不到你的 MAC 地址，浏览器生成版本 1 只能用随机节点 ID——而版本 7 做得更好，时间戳还能排序。检查模式仍然可以解析你粘贴的版本 1 和版本 6 UUID。
计算示例：读出 UUID 里的时间
RFC 9562 给出的版本 7 示例是 017F22E2-79B0-7CC3-98C4-DC0C0C07398F。第 13 位的 7 是版本号，第 17 位的 9 说明它属于 RFC 变体。前 12 位 017F22E279B0 是十六进制的 1,645,557,742,000 毫秒（自 1970 年 1 月 1 日起），即 2022-02-22T19:22:22Z，也就是北京时间 2022 年 2 月 23 日 03:22:22。RFC 里版本 1 和版本 6 的示例记录的是同一时刻，写成自 1582 年 10 月 15 日（格里历第一天）起的 138,648,505,420,000,000 个 100 纳秒：
| UUID | 版本 | 生成时间（UTC） |
|---|---|---|
017f22e2-79b0-7cc3-98c4-dc0c0c07398f | 版本 7 | 2022-02-22T19:22:22Z |
c232ab00-9414-11ec-b3c8-9f6bdeced846 | 版本 1 | 2022-02-22T19:22:22Z |
1ec9414c-232a-6b00-b3c8-9f6bdeced846 | 版本 6 | 2022-02-22T19:22:22Z |
版本 1 把时间拆成三段、低位在前，所以版本 1 的 UUID 不能按时间排序；版本 6 把相同的位按顺序排列。
重复的可能性有多大？
版本 4 的 UUID 有 122 个随机位，共有 2122（约 5.3 × 1036）种可能。根据生日问题，要生成大约 2.7 × 1018 个 UUID，出现至少一次重复的概率才达到 50%。按每秒十亿个的速度，需要大约 86 年。在十亿个 UUID 里出现任何重复的概率约为 1019 分之一。现实中的重复来自坏掉的随机数生成器——老旧的库，或用同一随机状态克隆出来的虚拟机——而不是数学本身。本页使用浏览器的密码学安全随机数生成器 crypto.getRandomValues。
格式与使用技巧
- 大小写：RFC 9562 建议输出小写，比较 UUID 时应忽略大小写。
- 花括号是 Windows 注册表、COM 和 .NET
Guid.ToString("B")的写法；URN（urn:uuid:…）用于 XML 和 RDF。 - 在 MySQL 里存储：用
BINARY(16)比CHAR(36)省一半以上空间、索引更小。MySQL 8.0 提供UUID_TO_BIN()和BIN_TO_UUID()进行转换；注意 MySQL 自带的UUID()函数生成的是版本 1。PostgreSQL 有原生的uuid类型。 - 在代码里生成：JavaScript 用
crypto.randomUUID()；Python 用uuid.uuid4()，3.14 起有uuid.uuid7()；Java 用UUID.randomUUID()；Go 常用github.com/google/uuid；PostgreSQL 用gen_random_uuid()，18 版起有uuidv7()；.NET 用Guid.NewGuid()，.NET 9 起有Guid.CreateVersion7()。 - 需要的是密码或密钥而不是 ID 时，请用密码生成器。UUID 放进接口时常和令牌一起出现，解析令牌可以用 JWT 解析。
UUID 在你的浏览器里生成，不会发送到任何地方，页面也不保留生成记录。
常见问题
UUID 和 GUID 有什么区别？
实际上没有区别。GUID（全局唯一标识符）是微软对同一种 128 位标识符的叫法。如今 Windows 和 .NET 生成的 GUID 就是版本 4 的 UUID，常写成大写并加花括号，例如 {0F8FAD5B-D9CB-469F-A165-70867728950E}。
版本 4 的 UUID 真的不会重复吗？
不能绝对保证，但对任何真实系统都足够了：122 个随机位意味着要生成约 2.7 × 1018 个，才有 50% 的概率出现一次重复。数据库里仍然建议给 UUID 列加唯一约束，几乎没有成本，还能拦住随机数生成器出错的罕见情况。
可以把 UUID 当作密码或令牌吗？
最好不要。RFC 9562 指出不应假定 UUID 难以猜测：版本 7 只有 74 个随机位，还带着可读的时间戳，有些库的随机数也不够安全。需要密钥时，请用专门的令牌，例如 32 个随机字节的 Base64，或者用密码生成器。
怎样判断一个字符串是不是合法的 UUID？
粘贴到检查或校验 UUID 即可。在代码里，正则 ^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$（忽略大小写）匹配标准变体中版本 1 到 8 的 UUID；Nil 和 Max UUID 需要单独判断。可以在正则表达式在线测试里试一试。
MySQL 主键用 UUID 好不好？
在 ID 需要在多处生成（多台服务器、离线的移动端）或不能暴露记录数量时很合适。做主键请优先选版本 7，时间有序的值能让 InnoDB 的聚簇索引保持紧凑；并用 BINARY(16) 存储，而不是 36 个字符的文本。
最后更新：2026年10月16日