UUID 生成器 — 在线生成 UUID v4 和 v7
即时生成加密随机 UUID。支持 v4（纯随机）和 v7（时间可排序，RFC 9562）。单个或批量生成最多 100 个。使用 crypto.randomUUID()，浏览器完成所有工作，不经过服务器。
UUID v4 (Random)
Generated using random numbers. No structure, completely random. Suitable for most use cases.
UUID v7 (Time-based)
Generated using a timestamp and random numbers. Sortable by time, improving database performance.
UUIDs (Universally Unique Identifiers) are 128-bit numbers used to identify information in computer systems. The probability of generating two identical UUIDs is virtually zero.
UUID 版本详解
UUID 是 128 位标识符，格式为 32 个十六进制数字分 5 组：550e8400-e29b-41d4-a716-446655440000。第 13 个字符是版本号（上面例子中的"4"表示 v4）。
UUID v4 是纯随机——122 个随机位加 6 个保留位（版本和变体标记）。碰撞概率低到离谱：你需要生成 2.71 × 10^18 个 UUID 才有 50% 概率出现一个重复。实际上就是"永远不会"。
UUID v7（定义在 RFC 9562，2024 年发布）是新成员。前 48 位放 Unix 时间戳，后面跟随机位。这意味着 v7 UUID 按时间排序——对数据库索引是巨大的胜利。PostgreSQL 和 MySQL 用随机 v4 UUID 做主键都会受苦，因为 B-tree 索引在随机插入时碎片化严重。v7 修复了这个问题，让插入永远追加到索引末尾。
什么时候用哪个：v4 用于不需要排序的场景（会话令牌、关联 ID、幂等键）。v7 用于数据库主键、事件 ID、或任何需要按创建时间排序的东西。如果你在 2024 年之后开始新项目，默认用 v7。
使用方法
- 选择 UUID 版本：v4（随机）或 v7（时间可排序）。
- 设置数量——1 个快速获取，最多 100 个批量生成。
- 点击生成，结果立刻出现。
- 复制单个 UUID 或全部复制。小写带连字符，直接粘贴可用。
什么时候会用到
分布式系统的数据库主键
自增 ID 在多写入节点时会冲突。UUID 让每个节点独立生成 ID，零协调。需要时间排序用 v7（大多数情况），明确不想暴露创建顺序用 v4。
API 幂等键
Stripe、AWS 和大多数支付 API 要求幂等键防止重复扣款。每个请求生成一个 v4 UUID——如果请求失败用同一个键重试，服务器知道这是重试而不是新扣款。
云存储的文件和对象命名
上传用户文件到 S3？用 UUID 做对象键。不会碰撞，不需要清理文件名，用 v4 不泄露上传顺序，用 v7 方便按时间列出。
分布式追踪的关联 ID
在请求入口生成一个 UUID，通过 header 传递给所有微服务。出问题时，用这个 UUID grep 所有日志就能看到完整请求路径。v4 最适合——不需要排序，只需要唯一性。
需要知道的事
v4 UUID 做数据库主键很糟糕（用 v7）
随机 v4 UUID 导致 B-tree 索引碎片化，因为插入落在随机位置。这意味着更多页分裂、更多磁盘 I/O、更慢的写入。基准测试显示 v7 UUID 在 PostgreSQL 中插入性能好 2-3 倍。如果已经在用 v4，不容易迁移——但新表用 v7。
UUID 不是密钥
UUID 是标识符，不是安全令牌。v7 UUID 泄露创建时间（时间戳就在前 48 位）。v4 UUID 是随机的但只有 122 位熵——对唯一性够了，对安全敏感的令牌不够。API 密钥或需要抗暴力破解的会话令牌，用 256 位随机值。
数据库里存 binary(16)，不是 varchar(36)
UUID 文本形式是 36 个字符（带连字符）。二进制是 16 字节——不到一半的存储。PostgreSQL 有原生 UUID 类型（16 字节）。MySQL 的 BINARY(16) 配合 UUID_TO_BIN() 效果好。当你有几百万行带 UUID 外键时，这很重要。
除非必须，不要去掉连字符
标准格式是 8-4-4-4-12 带连字符。有些系统去掉它们（32 个十六进制字符）。两种都有效，但连字符让 UUID 更可读，版本数字（第 13 位）更容易识别。除非系统明确要求去掉，否则保留连字符。
示例
UUID v4 — 纯随机
注意第 13 位的"4"（版本）和第 17 位的 8/9/a/b（变体）。
Input
版本: v4Output
f47ac10b-58cc-4372-a567-0e02b2c3d479UUID v7 — 时间可排序
注意第 13 位的"7"。前 12 个十六进制字符编码毫秒级 Unix 时间戳。
Input
版本: v7Output
018f6b2d-3c4a-7b12-9f8e-1a2b3c4d5e6f功能特点
- UUID v4：通过 crypto.randomUUID() 生成 122 位加密随机数
- UUID v7：毫秒精度时间戳 + 随机位（RFC 9562）
- 批量生成：一键最多 100 个 UUID
- 标准 8-4-4-4-12 格式，小写十六进制
- 一键复制单个或全部 UUID
- 100% 浏览器运行——零网络请求
常见问题
两个 UUID 会碰撞吗？
v4 的碰撞概率是 2^122 分之一（约 5.3 × 10^36）。换个说法：你需要每秒生成 10 亿个 UUID，持续 85 年，才有 50% 概率出现一次碰撞。任何真实系统中都不会发生。v7 碰撞风险更低，因为时间戳部分保证了不同毫秒生成的 UUID 永远不会碰撞。
数据库该用 UUID v4 还是 v7？
几乎总是 v7。随机 v4 UUID 导致 B-tree 索引碎片化——插入落在随机位置，引起页分裂，降低写入性能。v7 UUID 按时间排序，插入永远追加到索引末尾。PostgreSQL 基准测试显示 v7 插入吞吐量好 2-3 倍。唯一用 v4 的理由是你明确需要隐藏创建顺序。
能从 UUID v7 提取时间戳吗？
能。v7 UUID 的前 48 位就是毫秒级 Unix 时间戳。没有加密或隐藏。如果创建时间在你的场景中是敏感信息，用 v4。大多数应用（数据库 ID、事件日志）暴露创建时间没问题，而且实际上很有用。
UUID vs ULID vs nanoid——该用哪个？
UUID v7 和 ULID 解决同一个问题（时间可排序的唯一 ID），但 UUID v7 现在是正式 RFC 标准（9562）。nanoid 更短（21 字符 vs 36）但不是标准——适合 URL slug，不适合数据库主键。需要互操作性和标准合规用 UUID v7。需要短 ID 用于 URL 用 nanoid。
数据库里怎么高效存储 UUID？
用数据库原生 UUID 类型（PostgreSQL 有，16 字节）。MySQL 用 BINARY(16) 配合 UUID_TO_BIN(uuid, 1)——swap 标志重排字节让 v7 索引性能更好。高流量表永远不要存 VARCHAR(36)——浪费存储且比较更慢。几百万行时差异可测量。