Understanding UUIDs: What Those Hex Strings Mean

理解 UUID：那些十六进制字符串的含义

UUID stands for Universally Unique Identifier. It is a 128-bit label written as 32 hexadecimal characters grouped into five blocks separated by hyphens, like 550e8400-e29b-41d4-a716-446655440000. The idea is simple in principle: pick a value so large and so random that no two devices on the planet, picking independently, will ever collide. The math works out, and UUIDs are now the default identifier in APIs, databases, message queues, and distributed systems.

UUID 全称是 Universally Unique Identifier（通用唯一标识符）。它是一个 128 位的标签，通常写成 32 个十六进制字符、用连字符分成五段，例如 550e8400-e29b-41d4-a716-446655440000。原理并不复杂：把空间做得足够大、随机性做得足够强，让地球上任何两台设备各自独立生成都不会撞上。数学上确实成立，因此 UUID 已经成为 API、数据库、消息队列和分布式系统中的默认标识符。

The five versions of UUID

UUID 的五个版本

Not all UUIDs are random. RFC 9562 (which superseded RFC 4122 in 2024) defines five versions that produce the same shape but with very different internal structure. The version number is encoded in the first nibble of the third group, which is why ...-41d4-... above is a version 4 UUID.

UUID 并不都是随机数。RFC 9562（在 2024 年取代了 RFC 4122）定义了五个版本，它们格式相同，但内部结构差别很大。版本号编码在第三段的第一个十六进制位，所以上面例子里的 ...-41d4-... 是一个 v4 UUID。

• Version 1 — timestamp (100-nanosecond precision since 1582) plus the MAC address of the generating machine. Sortable, but leaks the hardware address and the time of creation.
• v1 —— 时间戳（自 1582 年起的 100 纳秒精度）加上生成机器的 MAC 地址。可排序，但会泄露硬件地址和创建时间。
• Version 2 — DCE security variant of v1, rarely seen today.
• v2 —— DCE 安全版的 v1，现已很少见。
• Version 3 — MD5 hash of a namespace and a name. Deterministic, but MD5 is broken for collision resistance.
• v3 —— 对"命名空间 + 名字"做 MD5 哈希。同一输入永远得到同一 UUID，但 MD5 的抗碰撞性已被攻破。
• Version 4 — 122 bits of randomness plus 6 fixed bits (version + variant). The default in nearly every language and library.
• v4 —— 122 位随机数加上 6 位固定位（版本 + 变体）。几乎所有语言和库的默认版本。
• Version 5 — like v3, but uses SHA-1. The right choice when you need a deterministic UUID from a name.
• v5 —— 与 v3 类似，但使用 SHA-1。当你需要从某个名字得到确定的 UUID 时，应选 v5。
• Version 7 — Unix-millisecond timestamp in the high bits, random in the low bits. New, sortable, and increasingly the best general-purpose choice.
• v7 —— 高位为 Unix 毫秒时间戳，低位为随机数。是较新的标准，天然可排序，正在成为通用场景下的最佳选择。

Why v4 won, and why v7 is taking over

为什么 v4 胜出，v7 又为何在崛起

Version 4 became the default because it requires no state — no clock, no MAC address, no namespace — and its 122 bits of randomness make accidental collisions astronomically unlikely. The birthday-paradox math says you would need to generate about 2.71 quintillion UUIDs before expecting a single collision. In practical terms: if a billion devices each generated a billion v4 UUIDs, the chance of even one duplicate is roughly 1 in 10^17.

v4 成为默认版本，是因为它不依赖任何外部状态 —— 不需要时钟、MAC 地址或命名空间 —— 而且 122 位的随机空间让意外碰撞的概率低到天文级别。根据生日悖论，大约要生成 2.71 × 10^18 个 UUID 才有 50% 概率出现一次碰撞。换句话说：10 亿台设备每台生成 10 亿个 v4 UUID，仍然撞号的概率大约只有 10^17 分之一。

But v4 has one big drawback: it is not sortable. A database index on a v4 column is essentially random, which means inserts constantly shuffle the B-tree, killing write performance and caching. Version 7 fixes this by putting a millisecond timestamp in the most significant bits, so newly created IDs sort naturally by creation time. The remaining bits are still random enough to make collisions practically impossible. For new projects in 2026, v7 is the right starting point.

但 v4 有一个明显缺点：不可排序。对 v4 列建索引几乎等同于随机写入，插入会不断打散 B 树，严重拖慢写入并破坏缓存。v7 通过把毫秒时间戳放到最高位解决了这个问题，新生成的 ID 自然按时间排序，剩余位仍然足够随机，碰撞概率几乎为零。对 2026 年启动的新项目，v7 是更合适的起点。

The nil UUID and format variants

nil UUID 与格式变体

The all-zeros UUID — 00000000-0000-0000-0000-000000000000 — is reserved as the "nil" UUID. It is not a valid v1–v7 (those require non-zero version and variant bits) and is commonly used as a sentinel for "no value", analogous to NULL in SQL or null in JSON. Many systems treat it as a magic value for "missing" or "uninitialized".

全零 UUID —— 00000000-0000-0000-0000-000000000000 —— 被保留为"nil"（空）UUID。它不是合法的 v1–v7（这些版本要求版本位和变体位非零），因此常用作"无值"的占位符，类似于 SQL 里的 NULL 或 JSON 里的 null。许多系统把它当作"缺失"或"未初始化"的特殊值。

The variant bits (the first two bits of the fourth group) identify the family of UUID. RFC 4122 variant is the one in everyday use (binary 10 in those two bits), but Microsoft historically used a different variant for GUIDs in COM/DCOM. In practice the two have been interoperable for decades, and modern libraries normalize to RFC 4122.

变体位（第四段的前两位）标识 UUID 所属家族。RFC 4122 变体是如今最常见的（这两位是二进制的 10），而微软历史上在 COM/DCOM 中使用过不同的变体。实际使用中两者几十年来一直互通，现代库都会规范化到 RFC 4122。

UUID vs auto-increment IDs in databases

UUID 与数据库自增主键

A 64-bit auto-increment ID is one third the size of a UUID, indexes beautifully, and reveals very little about your data volume. It is also a security risk: /users/12345 is trivially enumerable, and an attacker can walk from /users/1 to /users/1000000 by hand. UUIDs force attackers to guess — there is no public ordering to exploit.

64 位的自增主键只有 UUID 的三分之一大小，索引紧凑，泄露的信息也极少。但它有一个安全风险：/users/12345 这种链接极易枚举，攻击者完全可以手动从 /users/1 一路试到 /users/1000000。UUID 强制攻击者靠猜，公开链接里没有可利用的顺序。

A second, bigger reason: distributed systems. Once you have more than one writer, you either need a centralized counter (which becomes a bottleneck) or you need pre-coordinated ranges (which is brittle). UUIDs let every node generate IDs locally, with no coordination at all. For microservices, mobile clients generating offline IDs, or anything that gets replicated, UUIDs are simply easier.

更重要的原因是分布式系统。一旦有多个写入节点，你要么用中心化计数器（会成为瓶颈），要么预先分配号段（脆弱且难维护）。UUID 让每个节点本地生成 ID，完全不需要协调。对微服务、需要离线生成 ID 的移动端，以及任何需要复制的场景，UUID 都更省心。

The traditional objection — "UUIDs are too big and too random for primary keys" — is largely solved by v7, which sorts chronologically and indexes nearly as well as an auto-increment, while keeping every other advantage of UUIDs.

过去常见的反对意见 ——"UUID 太大、随机性太强，不适合做主键"—— 在 v7 上基本被解决了：v7 按时间排序，索引性能几乎和自增相当，同时保留了 UUID 的所有其他优势。

Other sortable IDs: ULID, KSUID, Snowflake

其他可排序 ID：ULID、KSUID、Snowflake

UUID v7 is not the only attempt at "sortable, distributed, random" IDs. The most notable alternatives:

UUID v7 不是唯一一种"可排序、分布式、随机"的 ID 设计。值得一提的替代方案包括：

• ULID (Universally Unique Lexicographically Sortable Identifier) — 26-character Crockford Base32 string encoding a 48-bit millisecond timestamp and 80 bits of randomness. Designed in 2016, influenced UUID v7's design.
• ULID（通用唯一字典序可排序标识符）—— 26 个 Crockford Base32 字符，编码 48 位毫秒时间戳和 80 位随机数。2016 年提出，UUID v7 的设计受到了它的影响。
• KSUID (K-Sortable Unique IDentifier) — 27-character Base62 encoding of a 32-bit second timestamp and 128 bits of randomness. Used at Segment and others.
• KSUID（K-Sortable Unique IDentifier）—— 27 个 Base62 字符，编码 32 位秒级时间戳和 128 位随机数。Segment 等公司在用。
• Snowflake (Twitter) — 64-bit integer with a 41-bit millisecond timestamp, 10-bit machine ID, 12-bit sequence. Compact and fast, but requires a coordinated machine ID assignment.
• Snowflake（Twitter）—— 64 位整数：41 位毫秒时间戳、10 位机器 ID、12 位序列号。紧凑且快，但需要预先分配机器 ID。
• ObjectID (MongoDB) — 12 bytes: 4-byte timestamp, 5-byte random per-process counter, 3-byte incrementing counter. Efficient and embedded-friendly.
• ObjectID（MongoDB）—— 12 字节：4 字节时间戳、5 字节进程内随机计数器、3 字节自增计数器。高效，对嵌入式场景友好。

All five share the same core idea: pack a timestamp at the top, fill the rest with randomness, accept some small chance of collision in exchange for natural sort order and zero coordination. The differences are mostly about string vs integer encoding, and how big a timestamp field you need.

这五种设计的核心思路一致：把时间戳放高位，其余位填随机数，承受极小的碰撞概率，换来自然排序和零协调成本。它们的差别主要在字符串还是整数编码，以及时间戳字段的大小。

Security caveats with UUIDs in URLs

URL 中使用 UUID 的安全注意事项

Putting a UUID in a URL makes that URL hard to guess, but it does not make it secret. UUIDs from a v4 source have ~122 bits of entropy, which is plenty against enumeration, but they can still leak through logs, browser history, referer headers, screen-shares, and shoulder-surfing. If the resource is truly sensitive, treat the UUID as an identifier, not as a capability — and put a real authorization check behind it. Never assume that "the URL has a UUID" means "the URL is safe".

把 UUID 放进 URL 能让链接难以被猜中，但并不等于"秘密"。v4 UUID 有大约 122 位熵，对穷举来说已经足够，但仍然会通过日志、浏览器历史、Referer 头、屏幕共享或旁观者泄露。如果资源确实敏感，应把 UUID 当作标识符，而不是"凭据"—— 真正决定能不能访问的是后端的授权检查。永远不要因为"URL 里是 UUID"就误以为它天然安全。

Try the tools

试试这些工具

Generate as many UUIDs as you need with the UUID generator. It supports v1, v4, and v7, and runs entirely in your browser, so no values leave your device.

用 UUID 生成器 一次性生成任意数量的 UUID，支持 v1、v4 和 v7。整个过程在浏览器内完成，不会有任何数据上传。