使用 Web Crypto API 的 crypto.randomUUID() 生成 1~100 个 v4 UUID，可切换是否带连字符，全部在浏览器内完成。UUID 的设计目标只有一个：无需协调即可铸造唯一标识符；它既不提供顺序，也不承载含义，更不简短。缺少这三样，几乎解释了人们在数据库或 URL 中使用它时遇到的所有问题。

情形	会发生什么	怎么处理
拿它当主键，数据库会变慢	v4 UUID 完全随机，因此插入位置会散布在整个索引中。B 树在末尾追加时效率最高，所以随机插入会频繁引发页分裂，导致索引碎片化。MySQL 的 InnoDB 中主键即聚簇索引——也就是说行数据本身按主键顺序排列——影响更大：规模到数千万行时，插入速度比自增主键慢数倍，索引体积也随之膨胀。此外，以 `CHAR(36)` 存储会在每个外键与每个索引上占用自增 `BIGINT`（8 字节）的 4.5 倍空间。	请使用按时间排序的 UUID v7——它的前 48 位是 Unix 毫秒时间戳，因此 UUID 会按生成顺序排序，插入集中在 B 树末尾。它保留了 UUID 的外观与唯一性，正是为解决这个问题而设计的版本（已在 RFC 9562 中标准化）。若环境不支持 v7，稳妥的做法是内部主键用自增，只把对外暴露的 ID 以 UUID 存在另一列。存储类型也请一并检视：用 `BINARY(16)` 取代 `CHAR(36)`，空间可减少一半以上（PostgreSQL 有原生的 `uuid` 类型）。先确认一下「你是否真的需要 UUID」——如果并不需要分布式或离线生成，自增序列就够了。
把 UUID 当成秘密来用	v4 UUID 的随机部分有 122 位，猜中在现实中不可能——仅凭这一点，就出现了「把 UUID 放进 URL，只有知道的人才能访问」这样的设计。但UUID 是标识符，并不是被设计来当作秘密保管的值：一旦放进 URL，它就会留在浏览器历史、Referer 头、访问日志、代理日志以及被分享出去的链接里。更糟的是，v1 内嵌了 MAC 地址与生成时间，压根就不是随机的——把 v1 用作会话 ID 或密码重置令牌是危险的。	请避开「知道 URL 就能访问」这类设计本身。访问控制应当交给认证与授权；「URL 难以猜中」至多只是辅助。确实需要让 URL 本身充当钥匙时（例如分享链接），请使用专门的令牌而非 UUID，并配上有效期与吊销机制——用 `crypto.getRandomValues()` 生成 32 字节随机数并做 Base64url 编码，是标准做法。并且，为避免该 URL 留在日志里，请把它放进片段（`#` 之后）而非路径，或者用 POST 发送——片段不会被发往服务器。UUID 说明的是「这是什么」，它并不证明「你是谁」。
写法不一致，同一个 ID 被当成两个	UUID 有好几种可接受的写法：大写与小写（`A1B2` 与 `a1b2`）、带或不带连字符（36 字符或 32 字符），以及用花括号包起来（`{...}`，微软的惯例）。RFC 4122 规定生成时用小写、接收时大小写皆可，但作为字符串比较，这些全都是不同的值。实务中，一个系统返回大写、另一个系统以小写存储，同一实体就会被创建出重复记录——而且能否匹配还可能取决于数据库的排序规则，于是行为因环境而异，原因也就难以定位。	请在系统入口处归一到单一形式——带连字符、小写最为通行，也符合 RFC 的建议。经 API 收到的值，在比较或存储之前务必过一次 `toLowerCase()`。存进数据库时，用二进制类型或原生 `uuid` 类型而非字符串，才是根本解法：二进制之下，写法问题根本不存在（PostgreSQL 的 `uuid` 类型会吸收输入写法，视作同一个值）。并且，凡是接收 UUID 的地方都请加上有效性校验——遇到格式不符的值时，在边界处直接报错，远比默默新建一条记录更容易追查。

关于碰撞，过度担心和毫不担心同样是错的。v4 UUID 拥有 122 位随机比特，即便每秒生成十亿个、持续一百年，碰撞概率依然可以忽略——但这个结论只在「随机源是密码学安全的」前提下成立。基于 Math.random() 拼装 UUID 的实现确实存在，那样的实现在现实中会碰撞。嵌入式设备与刚启动的服务器尤其容易熵不足，已有多台机器生成相同值的案例记录。浏览器请用 crypto.randomUUID()，服务端请用各语言的加密随机数 API。还有一点：crypto.randomUUID() 只在安全上下文（HTTPS 或 localhost）下可用——在公司内网的 HTTP 环境里「这个函数怎么不存在」，几乎都是这个原因。

📖 使用方法

1

设置生成数量

输入 1~100 的生成数量。
2

选择连字符选项后点击生成

选择无连字符后点击生成。
3

使用批量复制

点击批量复制将所有 UUID 复制到剪贴板。

❓ 常见问题

什么是 UUID v4?

UUID v4 是 RFC 4122 定义的 128 位随机标识符。

有碰撞(重复)的可能性吗?

理论上存在,但 122 位随机性使碰撞概率极低。

UUID 可以作为数据库主键吗?

是。但 UUID v4 随机性可能导致索引碎片化,需要顺序时考虑 UUID v7。

🐛 此工具出现问题了吗？

免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。

UUID v4 生成器

其他工具

相关文章

📖 常见的坑

📖 使用方法

❓ 常见问题

感谢您的反馈！