速查在线工具箱UUID 版本与格式速查
UUID 那串十六进制里藏着版本号、第 13 位能一眼看出生成方式，以及 v1 为什么会泄露 MAC 地址、v7 为什么更适合做数据库主键。
UUID 的结构是一段 32 位十六进制数，分成 5 组写成 8-4-4-4-12 的形式，共 128 位（其中 6 位被版本与变体占用，实际可用 122 位）。看起来杂乱无章，其实有两个位置是有确定含义的。
更值得关心的是版本：不同版本解决不同问题。v1 带时间与 MAC 地址，v4 纯随机，v7 是按时间排序的新方案。选错版本会导致主键索引性能差，或者无意间把设备信息写进数据库。
1结构：两个有含义的位置
看 550e8400-e29b-41d4-a716-446655440000 这一串，除了 32 个十六进制字符和 4 个连字符之外，还有两个位置携带信息。
| 位置 | 含义 | 在本例中 |
|---|---|---|
| 第 13 个十六进制字符（第三组的第一位） | 版本号，取值 1 到 8 | 4，说明这是 v4（随机） |
| 第 17 个十六进制字符（第四组的第一位） | 变体字段，标识 UUID 的具体变体 | a，属于 RFC 4122 变体 |
| 其余 122 位 | 真正的负载：时间、随机数或哈希结果 | 由生成方式决定 |
| 长度 | 32 位十六进制 + 4 个连字符 = 36 个字符 | 写进数据库时通常用 36 或 32 位定长字段 |
| Nil UUID | 00000000-0000-0000-0000-000000000000 | 全零，表示「不存在」的占位值 |
看到第三组以 `4` 开头几乎可以断定是随机 UUID（v4）；以 `1`、`3`、`5`、`7` 开头则是按时间、MD5、SHA-1、时间排序方式生成的。这一条在做数据排查时很实用。
2各版本对照
版本决定了「这串 ID 是怎么算出来的」，也决定了它带来的代价与风险。
| 版本 | 生成方式 | 排序友好 | 主要问题 |
|---|---|---|---|
v1 | 当前时间 + 网卡 MAC 地址 | 部分（时间在前的位） | 会泄露生成设备的 MAC 地址与生成时间，隐私风险 |
v2 | 时间 + 用户或组标识（DCE 安全） | 否 | 极少使用，规范中未明确 |
v3 | 命名空间 + 名称，用 MD5 计算 | 否 | 同一输入永远得到同一结果，可预测 |
v4 | 完全随机（122 位随机数） | 否 | 随机分布导致主键索引写入分散，高并发下性能较差 |
v5 | 命名空间 + 名称，用 SHA-1 计算 | 否 | 同 v3，只是哈希算法更可靠 |
v6 | v1 的时间段重新排列（RFC 9562） | 是 | 较新，生态支持仍在普及 |
v7 | Unix 毫秒时间戳 + 随机数（RFC 9562） | 是 | 较新，生态支持仍在普及；时间精度暴露到毫秒 |
v8 | 自定义方案（保留 122 位自由分配） | 取决于方案 | 需要自行约定，通用性差 |
3随机碰撞概率有多大
「UUID 会不会重复」是设计时最常被问的问题。答案取决于版本：随机版本靠概率保证，命名版本则是确定性的。
- v4 的空间
- 122 位随机，总空间约为 5.3 × 10^36 个
- 50% 概率碰撞所需的数量
- 大约 2.7 × 10^18 个，即约 271 亿亿个
- 直观换算
- 每秒生成 10 亿个 UUID，持续约 85 年才会累积到这个量级
- 结论
- 对任何现实系统而言，v4 的碰撞概率可以忽略。真正需要担心的不是碰撞，而是生成器的随机源质量
- 非随机版本的确定性
- v3 / v5 对同一命名空间与名称永远产生同一个 UUID。这是特性（可用于确定性去重），也是风险（可被猜到）
- 弱随机源的风险
- 若随机数生成器被种子预测或被克隆（如虚拟机镜像克隆后随机种子相同），可能批量产生重复值——这是真正出现过的故障类型
4UUID / GUID / ULID：怎么区分
三者经常被当成同义词，实际上只有两个是同一回事。
| 名称 | 关系 | 说明 |
|---|---|---|
| GUID | 等同于 UUID | 微软体系里的叫法，格式与语义一致 |
| UUID | 128 位标识符 | RFC 9562 定义，本文讨论的对象 |
| ULID | 另一种方案 | 26 个字符（Crockford Base32），前 48 位是毫秒时间戳，天然按时间排序，大小写不敏感 |
| Snowflake（雪花 ID） | 另一种方案 | Twitter 提出的 64 位整数，由时间戳、机器号、序列号组成，是数字型且有序 |
| 选择思路 | 字符串不透明 → UUID；要求有序且可读 → ULID；要求数字主键 → 雪花 ID |
5做主键时的实际取舍
把 UUID 用作数据库主键是常见需求，但有几个不那么直观的代价。
- 索引碎片
- v4 完全随机，插入位置分散，会导致 B 树索引频繁页分裂，写入吞吐下降。数据量越大越明显
- 推荐做法
- 需要 UUID 对外标识时，内部仍用自增整数做主键，另加一个唯一索引的 UUID 字段。这是最省心的折中
- 或用有序版本
- v7 与 ULID 都是时间前缀有序，既保留分布式唯一性，又避免随机插入带来的碎片。适合新项目
- 不要用 v1 暴露信息
- v1 内含 MAC 地址与生成时间，可能泄露设备与业务节奏。对外可见的 ID 不应使用 v1
- 存储形式
- 以字符串存（36 位）直观但占空间；转成二进制（16 字节）更省空间但排查时不便。按数据量权衡
- 不要当安全令牌
- UUID 随机但并非为「不可猜测的凭证」设计。会话令牌、重置密码链接应使用专门的加密随机令牌
看完就能用的站内工具
全部工具总览 →关于「UUID 版本与格式速查」的常见问题
UUID 会重复吗？
按版本区分。v4 是 122 位随机数，总空间约为 5.3 × 10^36，要达到 50% 的碰撞概率需要生成约 2.7 × 10^18 个，折算下来每秒生成 10 亿个也要持续约 85 年，因此任何现实系统都可以放心使用。v3 与 v5 是确定性的——同一命名空间加同一名称永远得到同一个 UUID，所以不会随机碰撞，但反过来说结果可被预测。真正需要警惕的是随机源质量：在虚拟机镜像克隆、容器快照恢复等场景下，如果随机种子被复制，可能出现批量重复。
UUID 做主键有什么问题？
主要问题是随机版本（v4）的插入位置分散，会导致数据库索引频繁发生页分裂，写入性能与索引体积都不理想，数据量越大越明显。常见的折中方案是：内部仍用自增整数作为真正的主键，另设一个带唯一索引的 UUID 字段用于对外暴露标识。如果希望直接用 UUID 做主键，可以选择时间前缀有序的 v7 或 ULID，它们在保留分布式唯一性的同时，插入位置基本递增，能避开碎片问题。
v1 和 v4 该用哪个？
绝大多数场景应选 v4。v1 由「时间 + 网卡 MAC 地址」生成，虽然带有时间信息、插入相对有序，但会把生成设备的 MAC 地址和精确生成时间写进 ID 里——如果这个 ID 对外可见，等于泄露了设备信息与业务节奏，存在隐私风险。v4 完全随机、不携带任何环境信息，虽然不适合做数据库主键（会带来索引碎片），但作为对外标识、文件名、请求追踪 ID 都非常合适。若确实需要有序又不想泄露 MAC，考虑 v7 或 ULID。
UUID 和 GUID 是同一种东西吗？
是的，只是叫法不同。GUID（Globally Unique Identifier）是微软体系中的称呼，其格式与语义和 RFC 标准定义的 UUID 完全一致，都是 128 位、8-4-4-4-12 的十六进制写法。所以在 Windows 相关文档里看到 GUID，在跨平台代码里看到 UUID，指的是同一件事。需要注意的是同一个项目里不要两种叫法混用，读代码的人容易被误导为存在两种不同的类型。另外 ULID 与雪花 ID 是另外的方案，不是 UUID 的别名。
继续查：相关内容
全部速查 →内容说明：本页速查数据由本站自行整理，事实性内容以对应官方规范与文档为准，未复制第三方速查表或百科的表述。数据最后核对日期：2026-10-05。若发现错误或已更新的标准，欢迎通过页脚反馈入口告知。