它如何工作
随机源是 crypto.getRandomValues()，与浏览器生成会话密钥用的是同一个加密级随机数发生器，不是 Math.random()。这样得到的 v4 不可预测，适合做不可猜测的标识符。
格式化时把版本位（第 7 个十六进制位固定为 4）和变体位（第 9 个十六进制位固定为 8/9/a/b）写死，这是 RFC 4122 的硬性要求——少了这两步，得到的只是「长得像 UUID 的随机串」，很多数据库与校验库会拒收。
v7 的前 48 位是毫秒级 Unix 时间戳，其余为随机位，因此按字典序排序即近似按时间排序，对 B+ 树主键非常友好，能显著减少随机写入带来的页分裂。同一毫秒内生成的多个 UUID 由计数器保证递增。
v4 与 v7 怎么选
| 对比项 | UUID v4 | UUID v7 |
|---|---|---|
| 结构 | 122 位全随机 | 48 位时间戳 + 74 位随机 |
| 有序性 | 无序 | 按时间有序 |
| 数据库主键 | 随机写入，索引易碎片化 | 顺序写入，索引友好 |
| 是否泄露时间 | 不泄露 | 可从 ID 推出生成时间 |
| 适用 | 对外暴露的不可猜 ID、会话 token | 内部主键、日志 ID、事件 ID |
若 ID 会暴露给外部且生成时间属于敏感信息，优先 v4；若纯粹用作数据库主键且写入量大，优先 v7。
常见问题
生成的 UUID 会重复吗？
v4 的碰撞概率极低：需要生成约 2.7×10¹⁸ 个才有 50% 概率出现一次碰撞。实践中可以忽略，但数据库层面仍建议保留唯一索引。
结果会被记录或上传吗？
不会。页面没有网络请求，也不写 Cookie 或 localStorage，刷新即消失。你可以打开开发者工具的网络面板验证。
为什么有的库说我的 UUID 不合法？
多半是版本位或变体位不对。手写的随机串常常只是「32 位十六进制」，缺少第 13 位固定为 4、第 17 位为 8/9/a/b 的约束。用本工具生成的一定符合 RFC 4122 / RFC 9562。
怎么用
- 在数量框里填要生成的个数，比如 20。
- 选版本：v4 完全随机，v7 按时间排序，做主键更合适。
- 按需勾选大写、去连字符、加前后缀等格式选项。
- 点「生成」按钮，列表里出现结果，可复制单条或一键下载全部。
适用场景
- 给新表的主键字段批量造一批测试数据。
- 为设备或会话生成唯一标识，避免编号撞车。
- 一次性生成几十个 ID 贴进脚本里跑初始化。
注意事项
- v7 按时间有序排列，同一批生成的前几位完全相同，别把它当随机熵使用
- 去掉连字符后是 32 位十六进制串，部分表字段按 36 位设计，插入前先确认长度
- 大写形式并非所有库都接受，标准写法是小写，不确定时保持默认即可
- 添加前后缀会改变总长度，字段若是定长类型需预留出前后缀的空间
- 生成依赖浏览器的加密随机数，很旧的浏览器可能退化成普通随机，质量下降
- 结果只存在于当前页面，刷新即消失，需要长期使用请自行复制保存