UUID v4 生成器：原理、选项与使用场景
UUID v4 的核心特性
本页面专门生成 UUID v4 标识符——一种由 122 位随机数构成的 128 位通用唯一标识符。标准输出为 36 字符的字符串，格式为 8-4-4-4-12 的十六进制表示（例如 550e8400-e29b-41d4-a716-446655440000）。与 UUID v7 或 ULID 的关键区别在于，v4 版本不嵌入时间戳，这意味着生成的 ID 之间没有时间顺序关系，排序时完全随机。
这种随机性来自浏览器内置的加密级伪随机数生成器（CSPRNG），所有计算都在本地完成，不向任何服务器发送数据。生成过程几乎瞬时完成，单次最多可生成 100 个 ID。
选项控制与即时反馈
页面提供三个可调选项，且任何选项变更都会立即触发重新生成：
- 数量（Count）：1 到 100 之间的整数。超出范围的值不会被接受。
- 大写（Uppercase）：关闭时输出小写十六进制（默认）；开启则输出大写字母。此选项仅改变显示形式，不影响底层 122 位随机数的值。
- 包含连字符（Include hyphens）：默认开启，输出标准 8-4-4-4-12 格式；关闭后输出连续的 32 个十六进制字符。
页面状态栏会显示“就绪（Ready）”、“已生成（Generated）”或“全部已复制（Copied all）”。每次生成后都会显示当前生成的 ID 数量。
底层原理：122 位随机性的结构
严格来说，UUID v4 标准（RFC 4122）定义的 128 位结构中，有 6 位是固定版本位和变体位标记（版本位在 4 位置，变体位固定为 10 开头），因此实际可用的随机位数为 122 位。这意味着：
- 单次生成的碰撞概率为 2⁻¹²²，约等于 1 / (5.3 × 10³⁶)。
- 即使每秒生成 10 亿个 ID，连续 100 年也几乎不可能产生一次碰撞。
- 32 个十六进制字符对应 128 位，其中 122 位随机，6 位固定。
输出格式的 8-4-4-4-12 模式中，第三个分组（第 13 至 16 位）的高 4 位固定为 4，表示版本号；第四个分组的左端固定为 8、9、a 或 b 之一（二进制 10xx），表示变体。其余所有位全部随机。
典型应用场景与取舍
UUID v4 适合以下场景：
- 安全令牌、会话 ID 或密码重置链接——需要不可预测的标识符，防止攻击者顺序枚举。
- 测试数据生成——快速填充数据库中的 ID 字段，无需关心顺序。
- 外部标识符——暴露给用户或第三方时，不希望泄露内部序号或创建时间。
- 匿名化处理——用随机 ID 替换真实主键，保护隐私数据。
但需要注意性能取舍：由于 UUID v4 不按时间排序，在 B-tree 索引中插入新记录时，随机键值会分散到索引树的各叶节点，导致大量页分裂和索引碎片。对于写密集型的 OLTP 场景，这会造成显著的性能下降。如果时间排序对您的应用很重要，应考虑使用 UUID v7（包含毫秒级时间戳）或 ULID。
操作细节与边界行为
- 复制单个 ID：点击列表中的任意一个 UUID，会自动复制到剪贴板。
- 复制全部：点击“全部复制（Copy all）”按钮，一次性复制所有生成的 ID。
- 状态提示：复制全部完成后，状态栏会显示“全部已复制”。下次生成时会重置为“已生成”。
- 格式变更：如果将生成类型从 UUID v4 切换为其他格式（如 UUID v7、ULID 或 NanoID），大小写和连字符选项可能发生变化，因为不同格式的表示规则不同。
生成性能与浏览器局限性
由于所有工作都在用户浏览器环境完成，不存在服务器延迟。生成 100 个 UUID v4 的时间目前普遍在 1 毫秒以下。唯一的性能限制是浏览器对 crypto.getRandomValues() 的调用频率——该 API 在主流浏览器中都能在短时间内提供足够多的随机字节。
需要注意一点：如果页面在新标签页或长时间未刷新的页面中使用，浏览器不会重新注入熵源，但 CSPRNG 的内部状态已经在前序调用中获得充分种子，因此不需要额外刷新。
常见问题
UUID v4 中的连字符是语法要求吗？
不是。连字符仅用于提高可读性，不携带任何信息。标准格式要求连字符（例如 RFC 4122 建议的表示法），但在很多数据库中可以直接存储去掉连字符的 32 字符字符串。
生成 100 个 UUID 时会不会产生重复？
概率可以忽略不计。按 122 位随机性计算，即使生成 100 亿个 ID，发生至少一次碰撞的概率仍然远远低于十亿分之一。实用上完全不必担心。
关闭连字符后字符数变少，随机性是否变差？
不会。随机性水平由 122 位决定，而不是由显示格式决定。移除连字符只是去掉了分隔符，32 个十六进制字符仍然完整保留了 128 位数据（含 122 位随机）。
为什么点击“大写”按钮后结果全变了？
每次改变选项都会触发重新生成，生成一组全新的随机 ID。这不是 bug，而是设计决定——确保每次选项变化后得到的 ID 集合都是一次完整的独立生成，避免用户误以为只是改变了格式而实际还是同一批数据。
生成的 UUID v4 是否适合用于数据库主键？
技术上可行，但需要权衡。对于读多写少的系统（如日志型数据）问题不大；对于写入频繁的 OLTP 系统，由于随机插入会导致索引页分裂和写放大，建议使用 UUID v7 或以序列、Snowflake ID 等具有时间顺序的值。
本地生成模式是否意味着完全私密？
是的。所有随机数都通过 crypto.getRandomValues() 在浏览器中生成，没有任何网络请求。生成结果不会离开您的设备，适合处理敏感数据。