UUID 是什么
UUID（Universally Unique Identifier，通用唯一标识符）是 RFC 4122 定义的 128 位标识符，通常写成 8-4-4-4-12 的十六进制字符串：
6ba7b811-9dad-11d1-80b4-00c04fd430c8
分组结构：
- 第 1 段（8 位）：时间/随机（低 32 位）
- 第 2 段（4 位）：时间（中 16 位）
- 第 3 段（4 位）：版本（最高 4 位）+ 时间（高 12 位）
- 第 4 段（4 位）：变体（最高 2 位）+ 随机
- 第 5 段（12 位）：节点 ID 或纯随机
核心设计目标：在不同系统间唯一标识一个对象，不依赖中心分配——两台不通信的服务器可以同时生成 UUID，几乎不会冲突。
v1 / v4 / v5 差异
| 版本 | 生成方式 | 有序性 | 适用场景 |
|---|
| v1 | 时间戳 + 机器 ID（MAC/clock_seq） | 时间有序 | 需要时间顺序、单机场景 |
| v4 | 纯随机（122 位） | 无序 | 通用主键、分布式 ID、默认选择 |
| v5 | SHA-1（命名空间 + 名称） | 确定性 | 稳定标识、跨服务 ID 复用 |
本站 UUID 生成器 支持这三种版本，v5 还内置了 4 个标准命名空间（URL/DNS/IPv4/OID）。
v1：时间戳 + 机器 ID
v1 用 60 位时间戳（100ns 粒度，从 1582-10-15 起算）加 14 位 clock_seq、48 位节点 ID（通常来自 MAC）拼接而成。优点：可排序，可按时间范围索引。缺点：泄露时间戳和机器 ID；时钟回拨可能产生重复。
v4：纯随机
v4 从密码学安全随机源取 122 位随机，再固定 4 位版本号和 2 位变体位。优点：最简单、无信息泄露、跨语言兼容最好。缺点：无序，作主键时数据库 B+ 树索引会有写放大。
v5：确定性哈希
v5 用 SHA-1 对「命名空间 UUID + 名称字符串」求哈希，取前 16 字节。优点：同一输入永远同一输出，可用于跨服务稳定标识。缺点：无随机性，如果命名空间暴露，可被枚举。
碰撞概率
UUID v4 的碰撞概率由生日悖论给出。生成 n 个 UUID 后，任意两个相同的概率约：
P ≈ n² / (2 × 2¹²²)
实际数字：
| 生成数量 | 碰撞概率 | 直觉 |
|---|
| 10 亿（10⁹） | ≈ 1.2 × 10⁻¹⁶ | 宇宙年龄内几乎不可能 |
| 1 万亿（10¹²） | ≈ 1.2 × 10⁻¹⁰ | 依然极低 |
| 1 千亿亿（10¹⁵） | ≈ 1.2 × 10⁻⁴ | 开始可测量 |
结论：常规业务量级下 v4 碰撞概率可忽略。真要担心，改用 UUID v7（RFC 9562）+ 主键唯一约束兜底。
与 ULID / nanoid 对比
UUID 不是唯一选择，还有两类常见 ID：
| 格式 | 长度 | 有序性 | URL-safe | 典型用途 |
|---|
| UUID v4 | 36 字符 | 无序 | 否 | 通用主键、分布式 ID |
| UUID v7 | 36 字符 | 时间有序 | 否 | 主键（避免 B+ 树写放大） |
| ULID | 26 字符 | 时间有序 | 是 | 时间序列主键、URL |
| nanoid | 16-22 字符 | 无序 | 是 | 分享链接、票据 |
| 自增整数 | 可变 | 严格有序 | 是 | 单机小数据量主键 |
选择原则：跨语言互操作必须用 UUID；时间序列主键用 UUID v7 或 ULID；短分享链接用 nanoid；单机小数据用自增整数。
隐私与安全考量
- v1 泄露信息：时间戳和机器 ID（MAC/IP）可被反推「这台机器何时生成了多少 UUID」。对外暴露 ID 时不要用 v1。
- v4 无信息泄露：用密码学安全随机源（如
crypto.getRandomValues），无可用信息。
- v5 可枚举：如果命名空间和名称空间可猜，攻击者可批量请求验证「这个 UUID 对应什么实体」。
- 避免可枚举 ID：外部 ID 用 UUID v4/v7 或 nanoid，避免用自增整数（易被遍历爬取）。
- 加密密钥不要用 UUID：UUID 只有 128 位随机，远低于对称加密密钥强度（128-256 位）。生成密钥用专门的 KDF 或 CSPRNG。
常见错误
- 用 Math.random() 造 UUID：JavaScript 的
Math.random() 不是密码学安全随机源，生成的 UUID 可被预测。必须用 crypto.getRandomValues()。
- 把 UUID 当加密密钥：128 位随机不够做对称密钥，需要至少 128 位密钥熵 + 密钥封装协议。
- v5 命名空间乱写：命名空间必须是合法 UUID 格式（8-4-4-4-12），自定义前要先验证。
- 大小写混用：UUID 规范小写，但某些系统接受大写。跨系统时统一小写，避免比较错误。
- 把 UUID 存成数字：UUID 是 128 位，超出任何语言的整数范围，必须存成字符串。
常见问题
Q：UUID 和 GUID 是一回事吗？
A：UUID 是 RFC 4122 定义的 128 位标识符标准；GUID 是微软的类似概念，格式与 UUID v4 一致。现代语境下可互换，UUID 更通用。
Q：UUID 会碰撞吗？
A：v4 在数学上几乎不可能碰撞：生成 10 亿个 v4 后任意两个相同的概率约 1.2×10⁻¹⁶。v1 时钟回拨可能重复；v5 是确定性哈希，同输入永远同输出。
Q：UUID 适合当主键吗？
A：v4 适合分布式主键，但会带来 B+ 树索引的随机写放大。高性能 OLTP 推荐 UUID v7（RFC 9562）或 ULID。单机小数据用自增整数即可。
Q：什么时候用 UUID v5？
A：v5 是确定性哈希（SHA-1 命名空间 + 名称），适合从同一输入稳定生成同一 ID 的场景。不需要随机性时用 v5，需要随机性时用 v4。
Q：UUID 有隐私/安全风险吗？
A：v1 会暴露时间戳和机器 ID，可被追踪；v4 用密码学安全随机源，无信息泄露。对外暴露 ID 建议用 v4/v7 或 nanoid，避免可枚举的数字 ID。
Q：UUID 和 ULID、nanoid 怎么选？
A：UUID v4/v7：通用、跨语言、128 位。ULID：时间有序、URL-safe、26 字符。nanoid：16 字符左右、URL-safe、短 ID。主键用 UUID v7 或 ULID；分享链接用 nanoid；跨语言互操作必须用 UUID。
免费生成 UUID v4 / v1 / v5
批量 1/10/100 · 大小写切换 · 命名空间预设 · 纯浏览器本地生成
打开 UUID 生成器 →
What UUID Is
UUID (Universally Unique Identifier) is a 128-bit identifier defined by RFC 4122, typically written as 8-4-4-4-12 hex groups:
6ba7b811-9dad-11d1-80b4-00c04fd430c8
Group structure:
- Group 1 (8 hex): time/random (low 32 bits)
- Group 2 (4 hex): time (middle 16 bits)
- Group 3 (4 hex): version (top 4 bits) + time (top 12 bits)
- Group 4 (4 hex): variant (top 2 bits) + random
- Group 5 (12 hex): node ID or pure random
Core design goal: uniquely identify an object across systems without a central authority — two non-communicating servers can generate UUIDs simultaneously and almost never collide.
v1 / v4 / v5 Differences
| Version | Generation | Ordering | Use cases |
|---|
| v1 | Timestamp + machine ID (MAC/clock_seq) | Time-ordered | Time-ordering needed, single-host |
| v4 | Pure random (122 bits) | Unordered | General PK, distributed IDs, default |
| v5 | SHA-1 (namespace + name) | Deterministic | Stable IDs, cross-service reuse |
Our UUID Generator supports all three, with 4 built-in namespaces for v5 (URL/DNS/IPv4/OID).
v1: Timestamp + machine ID
v1 uses a 60-bit timestamp (100ns granularity, since 1582-10-15) plus 14-bit clock_seq and 48-bit node ID (usually from MAC). Pros: sortable, indexable by time range. Cons: leaks timestamp and machine ID; clock rollback can produce duplicates.
v4: Pure random
v4 pulls 122 random bits from a CSPRNG, then fixes 4 version bits and 2 variant bits. Pros: simplest, no info leak, best cross-language compat. Cons: unordered; as a PK, causes write amplification in B+ tree indexes.
v5: Deterministic hash
v5 hashes "namespace UUID + name string" with SHA-1 and takes the first 16 bytes. Pros: same input always yields same output, useful for stable cross-service IDs. Cons: no randomness; if the namespace is exposed, IDs can be enumerated.
Collision Probability
v4 collision probability follows the birthday paradox. After generating n UUIDs, the probability of any two matching is roughly:
P ≈ n² / (2 × 2¹²²)
Concrete numbers:
| Generated | Collision probability | Intuition |
|---|
| 1 billion (10⁹) | ≈ 1.2 × 10⁻¹⁶ | Nearly impossible in the age of the universe |
| 1 trillion (10¹²) | ≈ 1.2 × 10⁻¹⁰ | Still very low |
| 10¹⁵ | ≈ 1.2 × 10⁻⁴ | Measurable |
Bottom line: v4 collisions are negligible at typical business scale. If truly concerned, switch to UUID v7 (RFC 9562) plus a unique constraint as a backstop.
vs ULID / nanoid
UUID isn't the only option. Two other common ID types:
| Format | Length | Ordered | URL-safe | Typical use |
|---|
| UUID v4 | 36 chars | No | No | General PK, distributed IDs |
| UUID v7 | 36 chars | Time-ordered | No | PK (avoids B+ tree write amplification) |
| ULID | 26 chars | Time-ordered | Yes | Time-series PK, URLs |
| nanoid | 16-22 chars | No | Yes | Share links, tickets |
| Auto-increment int | Variable | Strictly ordered | Yes | Single-host small-data PK |
Selection rules: cross-language interop requires UUID; time-series PK uses UUID v7 or ULID; short share links use nanoid; single-host small data uses auto-increment int.
Privacy & Security
- v1 leaks information: timestamp and machine ID (MAC/IP) can be reverse-engineered to see "how many UUIDs this machine generated when". Don't expose v1 externally.
- v4 has no info leak: uses a CSPRNG (e.g.,
crypto.getRandomValues), no extractable information.
- v5 can be enumerated: if the namespace and naming scheme are guessable, an attacker can batch-request to validate "which entity does this UUID map to".
- Avoid enumerable IDs: external IDs should use UUID v4/v7 or nanoid, not auto-increment integers (easy to scrape by enumeration).
- Don't use UUID as encryption keys: 128 bits of randomness is far below symmetric-key strength (128-256 bits). Generate keys with a dedicated KDF or CSPRNG.
Common Mistakes
- Generating UUID with Math.random(): JavaScript's
Math.random() is not a CSPRNG; resulting UUIDs can be predicted. Always use crypto.getRandomValues().
- Using UUID as encryption keys: 128-bit random is insufficient for symmetric keys; you need at least 128 bits of key entropy plus a key-encapsulation protocol.
- Writing invalid v5 namespaces: namespace must be a valid UUID (8-4-4-4-12). Validate before using custom ones.
- Mixed case: UUID spec is lowercase, but some systems accept uppercase. Standardize on lowercase for cross-system consistency.
- Storing UUID as a number: 128 bits exceeds every language's integer range; must be stored as a string.
FAQ
Q: Are UUID and GUID the same thing?
A: UUID is the 128-bit identifier defined by RFC 4122; GUID is Microsoft's similar concept with the same format as UUID v4. Interchangeable in modern usage, UUID is more universal.
Q: Can UUIDs collide?
A: v4 is mathematically almost impossible to collide: after generating 1 billion v4s, the probability of any two matching is ≈1.2×10⁻¹⁶. v1 can duplicate if the clock rolls back; v5 is a deterministic hash, same input always gives same output.
Q: Is UUID suitable as a primary key?
A: v4 is good for distributed PKs but causes random write amplification in B+ tree indexes. For high-performance OLTP, use UUID v7 (RFC 9562) or ULID. For single-host small data, use auto-increment integers.
Q: When to use UUID v5?
A: v5 is a deterministic hash (SHA-1 of namespace + name), suited for "stable ID from same input" scenarios. Use v5 when you don't need randomness; v4 when you do.
Q: Are there privacy/security risks with UUID?
A: v1 leaks timestamp and machine ID, allowing tracking; v4 uses a CSPRNG, no information leak. For external IDs, prefer v4/v7 or nanoid, avoiding enumerable numeric IDs.
Q: How to choose between UUID, ULID, and nanoid?
A: UUID v4/v7: universal, cross-language, 128 bits. ULID: time-ordered, URL-safe, 26 chars. nanoid: ~16 chars, URL-safe, short IDs. PK: UUID v7 or ULID; share links: nanoid; cross-language interop: UUID.
Free UUID v4 / v1 / v5 Generator
Batch 1/10/100 · Case toggle · Namespace presets · 100% browser-local
Open UUID Generator →