免费工具 UUID 在线生成：v4 / v7 批量生成与解析
一次生成最多 1000 个 UUID：随机的 v4，或按生成时间排序的 v7，格式按你的代码要求来（大写、32 位去横线、大括号、JSON 数组）。粘贴已有的 UUID，还能看出它的版本、变体，以及 v1、v6、v7 的生成时间。
- v4、v7（RFC 9562）
- 一次最多 1000 个
- 在浏览器里生成
生成或解析 UUID
每次打开页面都会生成 10 个新的 v4。切到 v7 得到按时间排序的 ID；或者点「示例：解析 RFC 9562 的例子」，看看一个 UUID 会透露什么。
1 到 1000。
每行一个。带横线、大括号、urn:uuid:、引号都可以。
91ba2582-a03e-4d48-95b0-bd28baa1698f
6754dcff-fa53-4a9c-ad40-ad02fa201895
36e4b8c6-0310-47e5-8839-b0b51b17bfa1
96e2f76f-82da-4bed-a448-6ed7b4666068
2615d19f-a4c3-44eb-a588-492a98a75b8b
1e0fcd1a-b383-48d3-96b9-f32ca362c0d9
8c16f43b-0fd8-490e-827e-90a5ba8e83fb
17297f5b-4701-45ec-b69e-0fbe9cd351a3
403950b6-33b8-45a1-bff5-8032a1f3f815
4c623d1c-2bdb-4716-8e26-8da4a2815e4d可以复制或下载。每点一次「重新生成」都是新的一批。
解析结果
时间按你浏览器的时区显示。
检查结果
版本 v1.0更新于 更新记录
选哪个版本，它会透露什么
UUID 是 128 位，写成 32 位十六进制。其中 6 位说明了其余部分是怎么来的。
版本号在哪
第三组的第一位就是版本：xxxxxxxx-xxxx-4xxx-… 是 v4，…-7xxx-… 是 v7。标准 UUID 第四组的第一位是 8、9、a 或 b。
v4：随机
122 位随机数。随机源可靠的话，要生成约 2.7 × 1018 个，出现一次重复的概率才到 50%（122 位的生日界）。它不透露任何信息，也没有顺序。
v7：按时间排序
前 48 位是 1970 年以来的毫秒数，新生成的 ID 排在旧的后面，数据库索引更紧凑；但看到 ID 的人也能知道它是什么时候生成的。
Nil 和 Max
00000000-0000-0000-0000-000000000000 和全 f 的 UUID 是特殊值，表示「无」和「全部」。可以当哨兵值，不能当真实 ID。
v7 会把生成时间精确到毫秒暴露出去。邀请链接这类公开 ID，在意这一点就用 v4。
三步
生成、选格式、复制。
-
1
选版本
一般 ID、token、对外公开的用 v4；数据库主键、需要按时间排序的事件 ID 用 v7。
-
2
定数量和格式
最多 1000 个。有的数据库和接口要大写或 32 位去横线；大括号是微软 GUID 的写法；JSON 直接得到数组。
-
3
复制或下载
整块复制，或下载 .txt（JSON 格式时是 .json）。要检查手上已有的 UUID，切到「解析已有的 UUID」。
v4 和 v7 怎么用这 128 位
RFC 9562（2024 年 5 月）取代了 RFC 4122，新增 v6、v7、v8。两种布局里，4 个版本位和 2 个变体位的位置都是固定的。
- 随机位必须来自密码学安全的随机数生成器（RFC 9562 第 6.9 节），本页用
crypto.getRandomValues - 同一毫秒内的 v7：本页把 12 位的 rand_a 当计数器（第 6.2 节的方法之一），一批 ID 严格递增
- 常见的 v4 写法：浏览器和 Node.js 的
crypto.randomUUID()、Python 的uuid.uuid4()、Java 的UUID.randomUUID()、MySQL 的UUID()则是 v1 - v7 比较新：Python 3.14 加了
uuid.uuid7()，PostgreSQL 18 加了uuidv7()；MySQL 8 可以用UUID_TO_BIN()存成 BINARY(16)
| 位 | v4 | v7 |
|---|---|---|
| 0–47（48 位） | 随机 | Unix 毫秒时间戳 |
| 48–51（4 位） | 版本 = 0100 | 版本 = 0111 |
| 52–63（12 位） | 随机 | rand_a：随机或计数器 |
| 64–65（2 位） | 变体 = 10 | 变体 = 10 |
| 66–127（62 位） | 随机 | rand_b：随机 |
三个 UUID，同一个时刻
RFC 9562 附录把同一时刻（美东时间 2022-02-22 14:22:22）分别编成 v1、v6、v7，解析后都能还原出来；v4 例子里没有时间可还原。
| UUID | 版本 | 解析出的时间（北京时间） | 说明 |
|---|---|---|---|
C232AB00-9414-11EC-B3C8-9F6BDECED846 | v1 | 2022-02-23 03:22:22.000 | 时间拆在几组里，低位在前 |
1EC9414C-232A-6B00-B3C8-9F6BDECED846 | v6 | 2022-02-23 03:22:22.000 | 同一时间，高位在前，所以能排序 |
017F22E2-79B0-7CC3-98C4-DC0C0C07398F | v7 | 2022-02-23 03:22:22.000 | 前 12 位十六进制就是 1645557742000 毫秒 |
919108F7-52D1-4320-9BAC-F847DB4148A8 | v4 | — | 随机，不含时间 |
时间用 Python 的 uuid 模块（v1）和直接读前 48 位（v7）核对过。点上面的「示例：解析 RFC 9562 的例子」能看到同样的结果。
UUID 常见的坑
UUID 很好生成，出问题多在下面几处。
用 Math.random() 拼 UUID
基于 Math.random() 自己拼的 UUID 不是密码学随机，可能出现重复。用 crypto.randomUUID() 或维护中的库。
随机 v4 当聚簇主键
随机主键会把写入打散到整棵 B+ 树（InnoDB 尤其明显）。v7 让新行都追加在末尾；存成 16 字节的 BINARY(16) 而不是 36 个字符，体积也能减半。
v1、v7 泄露信息
v1 可能带着生成机器的 MAC 地址，v7 带着生成时间。在意的话，别把它们放进公开链接。
用占位值当 ID
用 Nil UUID、"0" 或所有游客共用一个默认 ID，会把不相干的人合并成一条记录。没有真实 ID 时就留空。
人、设备、事件，各有各的 ID
统计靠 ID 把行为串起来。好的 ID 稳定、唯一、本身不是个人信息，你自己用户表里的 UUID 正好符合。
UUID 是什么？怎么在线生成？
UUID（通用唯一识别码）是 128 位的标识符，通常写成 8-4-4-4-12 分组的 32 位十六进制。不需要中心机构分配，各自生成实际也不会重复；GUID 是微软对同一东西的叫法。在本页选版本和数量，结果马上出来，可以复制或下载。
UUID v4 和 v7 有什么区别，选哪个？
v4 完全随机；v7 前 48 位是毫秒时间戳，按生成时间排序。数据库主键、事件 ID 这类需要按时间排、在意索引效率的用 v7；对外公开、不希望透露任何信息的（链接、token）用 v4。
UUID 会重复吗？
理论上会，实际上不会，前提是随机源可靠。v4 要生成约 2.7 × 1018 个，出现一次重复的概率才到 50%。真实发生的重复，几乎都来自糟糕的生成方式，比如基于 Math.random() 自己拼，或者克隆出来的虚拟机用了同一个随机种子。
32 位 UUID 和 36 位有什么区别？
是同一个值，36 位只是多了 4 个横线。很多国内项目把 UUID 去掉横线存成 32 位字符串；RFC 9562 规定的标准文本格式是带横线的，发给校验严格的系统前建议加回去。
怎么看一个 UUID 是哪个版本？
看第三组的第一个字符：…-4xxx-… 是 v4，…-7xxx-… 是 v7。也可以粘到「解析已有的 UUID」里，还能看到变体，以及 v1、v6、v7 的生成时间。
这里生成的 UUID 安全吗？
安全。UUID 在你的浏览器里用 crypto.getRandomValues 生成，和 crypto.randomUUID() 用的是同一个密码学安全随机源；不经过服务器，每点一次「重新生成」都是新值。