UUID 批量生成指南：v4 能当主键，不能当令牌

UUID 解决的是「多个地方各自造 ID 还不会撞」，不是「造一个别人猜不到的秘密」。这两件事经常被混在一起。

批量生成用在什么地方

给测试库灌数据、给日志加 trace id、给离线创建的草稿分配主键、给多个服务约定幂等键——这些场景的共同点是：没人想先去数据库取号，但又必须保证不重复，UUID 正好填这个空。

一次生成几十上百个，粘进 SQL 或 JSON 里就能用。它不按时间排序，所以生成的顺序和插入顺序无关，这一点在做数据对照时要注意，别把生成顺序当成业务顺序，它只是随机的产物。

标准 v4 是 32 个十六进制字符加 4 个连字符，第 13 位固定为 4（版本），第 17 位是 8、9、a、b 之一（变体位）。工具输出统一小写，随机数优先用 crypto.randomUUID()，不可用时退回 crypto.getRandomValues()。

存储优先用数据库原生的 uuid 类型，其次 binary(16)，最后才是 char(36)。大小写要在入库前统一，否则大小写敏感的排序规则下，同一个 ID 会变成两行对不上的数据。批量生成后也不要再截断。

v4 完全随机，插入位置也随机，写入量大的表会出现索引页分裂，比自增主键慢、索引也更占空间。既要唯一又希望大致有序，可以看 UUIDv7 或 ULID，它们把时间戳放在前面。

它不是安全令牌：没有有效期、不能撤销、不记录签发者，泄露了也无法作废。邀请码、重置密码链接、API key 都需要服务端签发、一次性、可过期的随机值，UUID 一个条件都不满足。

批量生成会重复吗？

v4 有 122 位随机位，工程上可以当作不会重复，即使每秒生成十亿个也远远够用。现实中的重复几乎都来自截断字符串或自己拼时间戳，而不是随机碰撞。

能当密码或邀请码吗？

不能。UUID 没有有效期、不可撤销、也无法追溯签发，泄露后无法作废；36 个字符对用户也太长。这类场景要用服务端签发的一次性令牌。

为什么不能按 UUID 排序？

v4 的位完全随机，字典序和时间没有任何关系。要按创建时间排序，用带时间前缀的 UUIDv7、ULID，或者单独存 created_at 字段。