UUID 生成器
批量生成 v4 随机 UUID，支持格式选项
UUID 版本怎么选：v4 很安全，但可能拖慢你的数据库
一个 UUID 长什么样
标准形式是 32 个十六进制字符，按 8-4-4-4-12 分成五段，共 36 个字符（含 4 个连字符）：550e8400-e29b-41d4-a716-446655440000。
其中第 13 位十六进制是版本号，第 17 位是变体号（RFC 4122 变体固定为 8、9、a、b 之一）。所以看一个 UUID 的第 13 位就能知道它是哪个版本。
各版本的区别
| 版本 | 生成方式 | 可预测性 | 典型用途 |
|---|---|---|---|
| v1 | 时间戳 + 节点（通常是 MAC 地址） | 可预测，且可能泄漏 MAC | 需要时间排序的老系统 |
| v3 | 命名空间 + 名字，MD5 哈希 | 确定性（同名同结果） | 由 URL/域名生成固定 ID |
| v4 | 纯随机（122 位） | 不可预测 | 通用默认选择 |
| v5 | 命名空间 + 名字，SHA-1 哈希 | 确定性，优先于 v3 | 由 URL/域名生成固定 ID |
| v6 | 时间排序 + 随机 | 不可预测 | v1 的排序友好替代 |
| v7 | Unix 毫秒时间戳 + 随机 | 不可预测 | 数据库主键（推荐） |
| v8 | 自定义 | 由实现决定 | 留给厂商实验 |
v4 的碰撞概率到底有多低
v4 有 122 位随机量，共约 5.3×1036 种取值。按生日悖论，需要生成约 2.7×1018 个 UUID 才会有 50% 概率出现一次碰撞。每秒生成 10 亿个，需要约 86 年。所以实践上可以当它不会碰撞——但"不会碰撞"不等于"不能用它做安全令牌"：v4 的随机性来自实现的随机源，规范并未要求必须用密码学安全随机数。要生成不可猜测的 token，请用专门的随机 API 而不是 UUID。
为什么 v4 会拖慢数据库
这是最容易被忽略的一点。多数关系型数据库的主键是 B+ 树索引，插入位置按主键顺序排列。
- 自增整数：新行总在末尾追加，页写满就开新页，顺序写、缓存友好。
- 随机 UUID（v4）：新行的位置随机落在整棵树的任意位置，导致随机写、频繁的页分裂（page split）和缓存命中率下降。索引体积也比整数大得多（16 字节 vs 4/8 字节），二级索引会更明显地膨胀。
- 时间有序 UUID（v7）：前 48 位是毫秒时间戳，新值单调递增，插入模式接近自增，同时保留全局唯一和不可预测性。
所以新系统如果要用 UUID 做主键，v7 是比 v4 更好的默认选择。已经在用 v4 且数据量大、写入频繁的系统，可以考虑改用 v7 或 ULID。ULID 与 v7 思路相同（时间前缀 + 随机后缀），区别是 ULID 用 Crockford Base32 表示成 26 个字符，肉眼可读、可排序。
要不要去掉连字符
连字符只是可读性分隔符，不含信息。去掉后是 32 个字符的紧凑形式，体积少 11%。数据库存储和 URL 里常用紧凑形式，展示给人看时再加回连字符。注意不要做一个"大小写敏感"的比较——十六进制的 A 和 a 表示同一个值，比较前统一大小写，否则会出现"看起来一样但不相等"的问题。
本工具支持生成 v1 / v4 / v7，可选大写、去连字符、批量数量。生成使用浏览器的密码学安全随机源，全程本地执行。
常见问题
UUID v4 会重复吗？
概率可忽略。v4 有 122 位随机位，生成 10 亿个 UUID 出现一次碰撞的概率约为十亿分之一量级。