UUID 版本怎么选

v4 随机

通用默认选项。122 位随机，碰撞概率极低。不含时间信息。

v7 时间排序

RFC 9562 (2024) 新增。前 48 位是毫秒时间戳，可用作数据库主键（顺序写入）。

v1 时间戳 + MAC

经典版本，含时间戳和 MAC 地址。浏览器出于隐私已不再暴露 MAC，本工具用随机值模拟。

v3 / v5 哈希

从名字 + 命名空间确定性派生。同一对输入永远生成同样的 UUID，适合文件指纹、内容哈希。

使用技巧

数据库主键：推荐 v7，因为顺序写入对 B+Tree 友好，避免 v4 的随机写入导致的页分裂。
不要把 UUID 当密钥：v4 包含 122 位熵，仅够标识，不足以作为密码学密钥。
v1 隐私问题：v1 的 MAC 地址节点在过去被用来追踪用户，RFC 4122 建议改用随机节点 ID。本工具默认如此。
本工具不持久化：批量结果只在你这次会话中保留，刷新即清空。需要长期使用请保存到本地。

FAQ

浏览器原生 crypto.randomUUID() 不好吗？

很好，HTTPS 下应优先用它。它只生成 v4。本工具额外提供 v7（时序主键）和命名空间 UUID。

v7 与 ULID 的区别？

ULID 是 26 字节字符串，UUID v7 是 16 字节二进制。两者设计思路类似（前 48 位毫秒时间戳）。UUID v7 的优势是与 UUID v4 同样的二进制长度，向后兼容 UUID 字段。

用「UUID 生成器」时最容易踩的坑是什么？

常见的易错点集中在四处：一是把百分数和小数混着填，比如 20 填成了 0.2；二是漏填选填项后直接按默认值算，得到一个看起来正常但不是你想要的数；三是中途改了其中一个输入却忘了重新计算，页面上还留着上一轮的旧结果；四是把页面上写的「参考值」当成了「准确值」往对外的材料里搬。改完任何一项输入，都重新点一次计算按钮再读结果。

「UUID 生成器」的适用边界在哪里？

UUID v1 / v4 / v7 生成、命名空间 UUID、批量生成与导出、UUID 解析（版本、变体、时间戳）。所有生成在浏览器本地完成。换句话说，它解决的是「按你给的条件做一次快速估算」这一类问题，不适用于需要查权威数据、核对官方文件，或者要逐条审合同、做专业判断的场景。凡是结果会直接影响到花钱、签约、对外承诺的事情，都应该回到原始资料和官方口径再确认一次，把这里的输出当作中间的一步，而不是终点。

「UUID 生成器」的结果应该怎么看？

先看最后给出的那个数值，再回到这一段解释里对照：UUID v1 / v4 / v7 生成、命名空间 UUID、批量生成与导出、UUID 解析（版本、变体、时间戳）。所有生成在浏览器本地完成。看的时候把「数值本身」和「数值成立的前提」分开看，前者是你填进去的东西算出来的，后者决定了它在什么情况下才算数。数值变大或变小分别代表什么，页面在这一节里已经写清楚了。

拿到「UUID 生成器」的结果后可以直接照着做吗？

把它当成做决定前的一份对照材料，比当成答案更稳妥：UUID v1 / v4 / v7 生成、命名空间 UUID、批量生成与导出、UUID 解析（版本、变体、时间戳）。所有生成在浏览器本地完成。这一页给出的是在当前输入下算出来的一个量级，它并不包含你的实际执行成本、突发情况和对方可能的变化。真正落地之前，再把结果和实际条件对一遍，看看哪些假设在现实里不成立。

UUID 生成器需要填写哪些信息？

「UUID 生成器」一共用到 8 个输入项：版本、数量、格式、显示版本与变体、命名空间、自定义命名空间 UUID（可选）、Name（任意字符串）、结果。这些字段在页面上是按计算顺序排下来的，前面的输入会直接影响后面的结果，所以不要跳过看不懂的那一栏。建议先把每个数字的单位口径对齐再动手填，单位不统一是这类计算里最常见、也最容易被忽略的错误来源。

开始用「UUID 生成器」之前需要先确认什么？

建议先确认三件事：一是你要解决的问题，是不是正好落在它的适用范围里，别拿一个相邻的工具硬套；二是手上每个数字的统计口径和时间点是否一致，比如同一年里有的按月、有的按年，直接混用会让结果失真；三是算完之后有没有留出复核的余地，比如把关键输入记下来，方便回看时知道当时用的是哪一组数。

谁适合用「UUID 生成器」，谁不适合？

适合的是手上已经有明确数字、需要快速得到一个量级参考的人，比如在做预算草案、给同事对齐口径、或者上课前先估算一遍的人。不适合的是想把结果当精确值直接对外承诺的人，也是不适合连输入项口径都还没定下来就开始算的情况——这种情况下先花几分钟把口径理清，比算完之后再来回改数字省事得多。

UUID 生成器

UUID 版本怎么选

使用技巧

FAQ

相关工具