UUID 生成器
批量生成 v4 UUID，随机源来自浏览器加密级 API。
说明
优先用 crypto.randomUUID()；浏览器不支持时回退到 crypto.getRandomValues() 手动拼装，仍然满足 v4 规范的随机性要求。
什么时候用
- 要给测试数据、CSV 或数据库种子行造主键：一次生成 50 个，直接粘进 INSERT 或夹具文件，不用装 uuidgen、也不用为每行跑一次命令。
- 需要一个不泄露时间和机器信息的请求 ID、幂等键或幂等 token：v4 全是随机位，不像 v1 会把时间戳和 MAC 地址编进去。
什么时候不用
- 打算用主键排序、或按创建时间分页：v4 完全随机，写入 B-tree 时页分裂分散，也不能从 id 判断先后，这类场景用 UUID v7、ULID 或自增主键加时间列。
- 要由同一个名字稳定生成同一个 ID（幂等导入、确定性测试夹具）：那是 v3（MD5）或 v5（SHA-1）命名空间 UUID，本工具只出 v4，每点一次都是新值。
限制与隐私
生成在浏览器本地完成，不上传、不落盘。优先 crypto.randomUUID，旧浏览器降级到 getRandomValues。限制：只出 v4，无 v1/v3/v5/v7；最多 100 个；不查重；randomUUID 要 HTTPS。
常见问题
v4 会重复吗？
理论上会，但概率可以忽略：122 位随机，即便生成 10 亿个，碰撞概率也只有 10 的负 19 次方量级。现实中的重复几乎都来自工程问题——多台机器各自生成、写库重试、复制粘贴时被截断。所以数据库仍要建唯一索引，把它当作真正的保证，别只依赖「应该不会撞」。
大写形式能存进数据库吗？
能，但要统一。RFC 9562 规定输出用小写，比较时不区分大小写；然而很多数据库的 collation、Redis 的 key、日志检索是区分大小写的，混着用就会出现「同一个 UUID 查不到」。建议存储和传输统一小写，只在展示层，或对接明确要求大写的老系统（部分 Oracle、SAP 接口）时转换。
能从 UUID 看出生成时间和机器吗？
v4 看不出来，除版本位和变体位之外全是随机数，没有时间、没有节点标识。会泄露信息的是别的版本：v1 带上生成时间和网卡 MAC（或随机 node），v7 带毫秒时间戳。本工具只生成 v4，所以不存在这类推断风险，但也意味着它不能当时间有序的 ID 用。