UUID v4 与 v7 该用哪个？

v4 是完全随机的 122-bit UUID（RFC 4122），适合不需要排序的场景；v7（RFC 9562, 2024）前 48 bit 是 Unix 毫秒时间戳，剩下 74 bit 随机，按时间单调递增，更适合作数据库主键（B-tree 索引友好，避免 v4 写入时的页分裂）。新项目优先选 v7。

NanoID 比 UUID 短，安全性是否足够？

21 字符的 NanoID（默认）字母表 64，碰撞空间 64^21 ≈ 1.3e38，与 UUID v4 的 5.3e36 同量级。即使每秒生成 1 亿个，要 1% 概率碰撞需 27 万年，足够用作数据库主键、文件名、URL slug。

为什么显示「您的浏览器不支持 crypto.getRandomValues」？

现代浏览器（2012 后）都支持。如果出现这条错误，说明你在 IE 或非 HTTPS 的 file:// 旧环境。任何 https:// 站点都会有该 API。

数据会上传到服务器吗？

不会。所有 ID 都在你的浏览器内用 crypto.getRandomValues 生成，从不发到服务器，可放心用于敏感系统。

UUID 生成器（v4 / v7）与 NanoID - 免费在线工具

常见使用场景

🗄️

数据库主键

UUIDv7 前 48 bit 时间戳让 B-tree 索引按写入顺序聚簇，比 v4 的随机分布写入快 3-10 倍。新项目优先选 v7。

🔗

短 URL / Slug

NanoID 21 字符 = UUID 36 字符同等碰撞空间，但更短更适合放进 URL。可用「无歧义」预设避免 0/O 1/I/l 混淆。

📦

批量种子数据

测试 / 性能 benchmark 时一次生成几千个 ID 灌进数据库，一键 10000 个 + 下载 .txt 比写脚本快。

🪄

Session / Token

生成临时 session ID、邀请码、防 CSRF token，crypto.getRandomValues 是浏览器真随机熵源，安全可用。

使用技巧

v4 vs v7 选哪个：作数据库主键选 v7（按时间单调递增，B-tree 友好）；只是「需要个随机 ID」选 v4 也行；想给人看的（URL、文件名）用 NanoID。
NanoID 自定义字母表：直接编辑「字母表」字段。注意：字母表越短、ID 越短，碰撞概率越高。基本规则：log2(字母表) × 长度 ≥ 132 bit ≈ 与 UUID 等价安全。
无歧义预设：去掉 0/O 1/I/l 后印在卡片上不会被认错；用作邀请码、礼品码场景的标准做法。
大括号 GUID 风格：`{xxxxxxxx-...}`，常用于 .NET / Windows Registry / Visual Studio 项目文件。
批量大于 10000？：生成几万个 ID 仍很快（每个约 1µs），但浏览器渲染巨大文本会卡顿。建议分批或直接用脚本。

UUID v4 / v7 与 NanoID批量生成器

常见使用场景

使用技巧

UUID v4 / v7 与 NanoID
批量生成器