UUID 生成器
批量生成 UUID v4（随机）、v7（时间有序）与 v1 风格（时间戳 + 随机节点），支持大小写、去连字符，并能校验已有 UUID 的结构、版本位与变体位。
浏览器本地运行所有计算都在你的浏览器里完成，数据不会离开本机。
v3 / v5（命名空间散列，需要 MD5 / SHA-1）暂未提供；v1 使用随机节点，不读取 MAC 地址。
8f0a1b2c-3d4e-4f5a-8b6c-7d8e9f0a1b2c
校验 UUID
这个工具能做什么
- 给数据库主键、请求 trace id、测试数据填 UUID：一次生成 1–1000 个，复制走直接用。
- 需要时间有序的键时选 v7：前 48 位是毫秒时间戳，同一毫秒内序号递增，写进索引不会像 v4 那样随机跳页。
- 检查一个已有 UUID 是否合法：核对 8-4-4-12 结构、十六进制字符、版本位与变体位，并指出具体是哪一项不合法。
- 反查 v1 / v7 里内嵌的时间：粘贴一个 UUID 就能看到它是哪一刻生成的，方便对日志。
示例
输入
f81d4fae-7dec-11d0-a765-00a0c91e6bf6
输出
校验结果：合法 版本：v1 变体：rfc4122 内嵌时间：854991792216（1997-02-03T17:43:12.216Z）
示例用的是页面里预置的经典 v1 样例，它确实来自 1997 年。生成出来的 UUID 每次都不一样，所以示例给的是「校验已有 UUID」这条路径的结果；生成结果的格式选项有大写与去掉连字符。
常见问题
v4、v7、v1 该选哪个？
默认用 v4：122 位随机，最通用、不可预测，适合对外暴露的 ID。要按时间排序、做数据库主键用 v7，它在同一毫秒内也能保持递增。v1 是历史格式，这里用随机 node 代替 MAC 地址，兼容老系统时可以选，但不要指望它的唯一性保证。
v1 为什么不用真实 MAC 地址？
RFC 4122 的原始 v1 把网卡 MAC 写进 node 字段，会泄露硬件信息甚至被用来追踪设备。这里的实现改用随机 node 和随机 clock_seq，所以是「v1 风格」而不是严格意义上的 v1，代价是失去了跨机器不冲突的强保证。
校验为什么会判我不合法？
常见原因：长度不是 32 个十六进制字符（去连字符后）、连字符位置不对、第 13 位（版本位）不是 1–8、第 17 位（变体位）不属于 RFC 4122 的 10xx 范围。nil（全 0）和 max（全 F）作为特殊情况被接受。
UUID 会重复吗？
v4 有 122 位随机，要生成约 2.7×10^18 个才有 50% 概率撞一次，实际使用中不必担心。v7 在同一毫秒内用序号保证有序不重复。真正的风险来自伪随机源被污染或人为复制粘贴，而不是算法本身。
生成结果会发给服务器吗？
不会。随机数来自浏览器的 crypto.getRandomValues，生成与校验都在本地完成，不发送任何请求、不写任何存储。如果运行环境没有 crypto，工具会直接报错而不是退回 Math.random。
关键词：uuidguidv4v7v1uuid 生成随机 id时间有序校验rfc 9562