UUID 生成指南：批量生成 v4 与正确用法

什么时候真的需要 UUID

多个地方都要自己造 ID、事后又不用对账的时候，UUID 才划算：浏览器离线建草稿、手机在弱网下排队记录、两个服务往同一张表里插数据、一条请求在五个日志里要串起来、给合作方一个猜不出来的资源标识。这些场景的共同点是：没人愿意或没办法先去数据库取号。

反过来说，单库单表、写入量不大的后台，自增 bigint 更省空间、索引更快、排查问题时也更好读。订单号、快递单号这种要给人念的编号同样不该用 UUID——36 个字符没人能在电话里念对。

• 适合：分布式主键、离线生成、trace id、幂等键、测试数据
• 不适合：要人读的单号、短链、邀请码
• 更不适合：密码、接口密钥、会话 token

怎么生成、怎么存才不出错

v4 的格式是 8-4-4-4-12 共 32 个十六进制字符加 4 个连字符，第 13 位固定是 4（版本号），第 17 位是 8、9、a、b 之一（变体位）。这两处不对，基本可以判断不是标准 v4。

大小写只是书写差异，a 和 A 是同一个值，但存进数据库前必须统一。混用在大写敏感的排序规则下，同一个标识会变成两行永远对不上的数据。建议统一小写：Postgres 的 uuid 类型和多数库的默认输出都是小写。

• 存储优先用数据库原生 uuid 类型，其次 binary(16)，最后才是 char(36)
• 别为了建索引再套一层 md5() 或 substring()，那是拿唯一性换性能
• 批量生成后不用手工去重，真正出事的是自己截断字符串
• 服务之间要约定连字符的取舍，一边带一边不带，联表会静默返回 0 行

局限：顺序随机，猜不到也不等于安全

v4 完全随机，插入位置也随机，索引页分裂多，写入量大的表会比追典型的自增主键慢，索引也更占空间。既要唯一又希望大致有序，可以看 UUIDv7（毫秒时间戳在前）或 ULID，两者都能按创建时间排序。

另一个常见误解是「猜不到＝安全」。UUID 不会过期、不能撤销、也没有签发记录，所以不能当密码重置链接里的 token 或接口密钥。这类场景需要服务端签发、一次性、有有效期、能主动作废的随机值。