如何通过UUID.randomUUID()高效创建独一无二的订单编号？

本文共计932个文字，预计阅读时间需要4分钟。

在生成订单号时，直接使用 `UUID.randomUUID()` 方法并不适合直接作为订单号，因为其生成的字符串仅由字符组成，缺乏业务规则，难以保证唯一性和可读性。更好的做法是将 UUID 作为订单号的一部分，结合业务规则进行定制化处理。

以下是一个简化的例子，展示如何结合 UUID 和业务规则生成高质量的订单号：

为什么不能直接用 UUID 当订单号？

虽然 UUID 全局唯一、无需中心协调，但存在几个实际问题：

• 长度过长（36 位含连字符），不利于展示、输入和日志排查
• 含字母和连字符（如 550e8400-e29b-41d4-a716-446655440000），部分老系统或第三方接口可能不兼容
• 无业务含义，无法体现时间、商户、渠道等信息，不利于运营分析和对账
• 随机性强，缺乏可读性和趋势性，客服或用户难以感知新旧顺序

推荐做法：用 UUID 做唯一性保障，再封装成业务友好的格式

思路是保留 UUID 的唯一性优势，同时压缩、编码、拼接业务字段。例如：

• 截取 + Base32 编码：取 UUID 的 byte 数组（16 字节），Base32 编码后约 26 位，无符号、无连字符、URL 安全。