UUID 生成器

Q: UUID 和自增 ID 哪个好？

各有优劣。自增 ID 简单、有序、索引性能好，但暴露记录数量、不支持分布式生成。UUID 天然支持分布式、不暴露信息量，但占空间大（36 字符 vs 4-8 字节）、索引性能略差。现代系统通常根据场景混合使用。

Q: UUID 做数据库主键会拖慢写入吗？

v4 会：完全随机导致 InnoDB 的 B+ 树聚簇索引频繁页分裂与随机 IO，大表写入吞吐可降一个数量级。缓解方案：① 用 v7（时间前缀，近似顺序写入）；② 存 BINARY(16) 而非 CHAR(36)，省一半空间且比较更快；③ 自增 ID 做主键、UUID 做对外暴露的业务标识（防止 ID 遍历泄露业务规模）。

Q: UUID 会重复吗？

v4 理论上会，实际不会：122 位随机空间下，每秒生成 10 亿个、连续 85 年才有一次 50% 碰撞概率，单系统生命周期内可视为零。但前提是真随机源——浏览器 Math.random() 不是密码学随机，本工具用 crypto.randomUUID()（CSPRNG）；自建生成器若用了弱随机源（如低熵种子），碰撞风险真实存在（2013 年 Android SecureRandom 漏洞即此类）。

Q: UUID 和 ULID、NanoID 怎么选？

三者都解决分布式唯一 ID：UUID v4/v7 是国际标准（RFC 9562），生态最广；ULID 128 位、26 字符 Crockford Base32，时间有序、URL 友好；NanoID 可定制长度与字母表（默认 21 字符），同等碰撞概率下最短。选型：要兼容性与中间件原生支持选 UUID v7；要短且时间有序选 ULID；前端轻量场景选 NanoID。

Q: 为什么有的 UUID 第 13 位总是 4？

那是版本号位：UUID 格式 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx 中 M 是版本（4=v4 随机、7=v7 时间序），N 的高 2 位是变体（IETF 标准为 10xx，显示 8/9/a/b）。所以正规 v4 的第 13 位恒为 4、第 17 位只可能是 8/9/a/b 之一。校验 UUID 合法性时这两个位置是必查点。

Q: UUID 需要保密吗？

看用途：作为纯标识符（数据库 ID、文件名）无需保密，它只保证唯一、不保证不可猜性之外的任何安全属性；作为能力凭证（如未登录态的访问令牌、分享链接）就必须视同密钥——此时应使用 ≥128 位 CSPRNG 随机串并配合过期时间，而不是"反正 UUID 长就安全"。公开暴露 v1 UUID 还会泄露生成机器的 MAC 地址与生成时刻。

Q: JavaScript 生成 UUID 的正确方式？

浏览器与 Node 16.17+ 直接用内置 crypto.randomUUID()——CSPRNG 实现的 v4，一行搞定且无需依赖。老环境用 crypto.getRandomValues 手写 122 位填充。绝对禁止 Math.random() 拼接——其种子熵仅 32-52 位，碰撞概率从"宇宙级"降到"可实测复现"，session 预测攻击真实发生过。

Q: UUID 能转回原始信息吗？

v4 不能——122 位全是随机数，不含任何可还原信息；v1 可以从结构位反推出 MAC 地址与大致生成时间（隐私缺陷）；v7 前 48 位直接就是毫秒时间戳，可读出生成时刻；v5 由命名空间+名字哈希而来，理论不可逆但小字典可碰撞还原。需要"可解码"的标识请用结构化编码（如 Snowflake ID 明含机房+机器+序列），那是另一种设计取向。

Q: 分布式系统为什么需要 UUID？

自增 ID 在分库分表下必然冲突，需要中心发号器（成为单点）。UUID 让任意节点独立生成全局唯一 ID：无协调、无网络往返、水平无限扩展，配合 v7 还能保持时间有序。代价是更长（36 字符 vs 数字）、可读性差、v4 索引效率低。工程折中：对内自增 ID、对外 UUID；或直接 v7/Snowflake 一肩挑。

Q: 批量生成 UUID 有什么性能注意？

CSPRNG 速度足够（crypto.randomUUID 每秒千万级），瓶颈通常在序列化与存储：批量插入数据库时用 BINARY(16) 存储 + 批量 INSERT，比 CHAR(36) 单条插入快数倍；前端一次渲染数万个 UUID 字符串会卡主线程，分批生成或 Web Worker。离线批量场景也可考虑预生成 ID 池，但失去了"按需生成"的意义。

什么是UUID 生成器？

UUID（Universally Unique Identifier，通用唯一标识符）是 128 位的标识符，标准格式为 8-4-4-4-12 的十六进制字符串：xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx。碰撞概率极低——生成 10 亿亿个 UUID 后，两个 UUID 相同的概率仅约 50%。

UUID v4 完全基于随机数：122 位随机 + 6 位固定标识（版本号 4 与变体）。它不需要中心协调器，不暴露任何系统信息（不同于 v1 包含 MAC 地址和时间戳），是目前使用最广泛的 UUID 版本。

本工具使用浏览器的 crypto.randomUUID() API——它基于密码学安全伪随机数生成器（CSPRNG），比 Math.random() 更适合生成标识符。

UUID 的 6 个版本各有适用场景：v1 基于时间戳+MAC 地址，适合需要可排序的数据库主键；v3/v5 基于命名空间+名称的哈希，同一名称永远生成同一 UUID（用于去重）；v4 完全随机，最常用于通用标识；v6/v7 是较新的有序版本，针对数据库索引性能优化。本工具默认生成 v4，但理解版本差异有助于在与他人数据交互时选择正确的方案。

UUID v4 格式：xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx（122 位随机）

UUID v4 由 122 位随机数 + 6 位固定位（版本号 4 与变体）构成，格式 8-4-4-4-12 十六进制（如 550e8400-e29b-41d4-a716-446655440000）。碰撞概率：生成 10 亿亿（10¹⁸）个 UUID 的碰撞概率约 50%，日常系统视为唯一。v4 完全随机；v7（RFC 9562，2024）前 48 位嵌入毫秒时间戳，兼顾唯一性与索引有序性，是数据库主键新首选。

UUID 各版本对比与选型
版本	生成依据	有序性	唯一性保障	典型用途
v1	时间戳+MAC 地址	大致有序	MAC+时钟序列	遗留系统，暴露 MAC 有隐私风险
v4	纯随机 122 位	无	概率唯一	通用标识/文件名/会话 ID（最常用）
v5	命名空间+名字 SHA-1	无	确定性	同一名字恒得同一 UUID
v7	毫秒时间戳+随机	时间有序	时间+随机	数据库主键新推荐（索引友好）
v8	自定义	取决于实现	自定义	厂商实验场景

如何使用UUID 生成器

1
输入生成数量（1-100）。
2
点击「生成」批量生成 UUID v4。

计算示例

例 1标准 UUID

550e8400-e29b-41d4-a716-446655440000——第 13 位固定为 4（v4），第 17 位为 8/9/a/b 之一。

例 2微服务间的请求追踪 ID

网关为每个请求生成一个 UUID v4 写入 X-Request-ID，下游服务全部透传——日志聚合时一个 grep 就能拉出请求全链路。UUID v4 随机位 122 bit，日采 10 亿条请求，碰撞概率仍 <10^-17，不需要中心化发号器。

注意事项

UUID v4 不适合用作安全令牌——它只保证唯一性，不保证不可预测性（虽然 crypto.randomUUID 是 CSPRNG）。
需要排序的场景考虑 UUID v7（时间有序）——v4 完全随机，不适合作为数据库主键（索引性能差）。
UUID v4 适合「分布式唯一」，不适合「顺序排序」——时间戳不单调，做主键会引发 B+ 树页分裂，数据库场景考虑 UUID v7（时间有序）或雪花 ID。

常见问题