是的。v4 和 v7 都用 crypto.getRandomValues 安全随机 API。v4 有 122 比特熵, v7 有 74。

为什么 v7 适合数据库键?

v7 UUID 按创建时间排序, 插入总在 B-tree 索引末尾而非随机位置。避免页分裂, 大幅提升写吞吐。

两个 UUID 会碰撞吗?

理论上可以。v4 需生成 ~10¹⁸ 才有 50% 碰撞风险。v7 同毫秒内为 2⁷⁴ — 实际上不可能。

是。GUID 是 Microsoft 对 UUID 的称呼。同样格式, 同样唯一性保证。

8-4-4-4-12 hex 字符用连字符分隔。共 32 hex 字符 + 4 连字符 = 36 字符。RFC 约定小写。

v1 包含 MAC 地址, 隐私泄漏。需要时间排序 ID 而不暴露硬件标识符就用 v7。

本工具不直接支持。把 UUID 16 字节编码为 URL Safe Base64 得 22 字符 ID, 适合短 URL。

不会。生成全部在本地。

v4 / v7 切换, 一键生成大量 UUID。完全随机用 v4, 数据库主键等需要时间排序场景用 v7。

UUID v4 是纯随机 — 122 个随机比特加 2 个版本/变体比特, 给出约 5.3 × 10³⁶ 种可能。两个碰撞基本不可能。不需要排序的场合用 v4, 例如 API 请求 ID 或匿名用户标识。

UUID v7 (RFC 9562, 2024 年发布) 以 48 比特 Unix 毫秒时间戳开头, 后跟 74 比特随机。按字典序排序就是创建顺序 — 对数据库性能影响巨大: 主键按时间排序意味着插入总在 B-tree 末尾, 没有随机页分裂。新数据库主键用 v7。

v4 与 v7 都用 crypto.getRandomValues — 浏览器加密学安全的随机源, HTTPS 与密码管理器使用的是同一原语。v4 把 122 比特填随机。v7 按 RFC 拆分 48 比特时间戳 + 74 比特随机加版本/变体标记。

生成在浏览器内进行。UUID 不存储不传输。生成 100 个 v4 间碰撞的概率天文数字小 — 远低于 CPU 中宇宙射线翻转比特的概率。

v4 UUID 作为数据库主键性能不及自增整数, 因为随机值导致插入时 B-tree 页分裂。v7 解决此问题 — 想要 UUID 优势又无索引痛点的话用 v7。

对用户暴露 UUID 时, 可猜测性很重要。v4 有 122 比特熵不可猜测。v7 泄漏创建时间, 多数场景没问题但若创建时间敏感则不适。

UUID 含连字符共 36 字符 (32 hex + 4 hyphens)。二进制 16 字节, 文本 36 字节。极高基数列考虑用 BINARY (16) 或原生 UUID 类型而非 VARCHAR(36)。