UUID.randomUUID() 不适合直接用作订单号，因其长度过长（36位）、含连字符和字母、无业务含义、缺乏可读性和时序性；推荐结合时间戳、商户号等业务字段及Base32编码等定制化处理来生成简洁、唯一、可读的订单号。
UUID.randomUUID() 本身不适合直接用作订单号，但可以作为生成高质量订单号的底层基础——关键在于不能裸用 UUID 字符串，而要结合业务规则做定制化处理。
为什么不能直接用 UUID 当订单号？
虽然 UUID 全局唯一、无需中心协调，但存在几个实际问题：
- 长度过长（36 位含连字符），不利于展示、输入和日志排查
- 含字母和连字符（如 550e8400-e29b-41d4-a716-446655440000），部分老系统或第三方接口可能不兼容
- 无业务含义，无法体现时间、商户、渠道等信息，不利于运营分析和对账
- 随机性强，缺乏可读性和趋势性，客服或用户难以感知新旧顺序
推荐做法：用 UUID 做唯一性保障，再封装成业务友好的格式
思路是保留 UUID 的唯一性优势，同时压缩、编码、拼接业务字段。例如：
-
截取 + Base32 编码：取 UUID 的 byte 数组（16 字节），Base32 编码后约 26 位，无符号、无连字符、URL 安全。Java 可用
java.util.Base64.getEncoder().encodeToString()配合自定义 Base32 实现，或引入com.github.f4b6a3.uuid:uuid-util - 时间戳 + UUID 后缀：拼接 13 位毫秒时间戳（如 20240520103045123）+ 截短 UUID（如取后 8 位 hex），得到类似 20240520103045123a1b2c3d 的结构，兼顾时序与唯一性
- 商户号 + 时间 + UUID 摘要：例如 M1001_240520_7f8a3e1d，其中 7f8a3e1d 是 UUID 的 MD5 后 8 位 hex，既缩容又避免明文暴露 UUID
必须注意的坑
即使基于 UUID 构建，也要规避常见错误：
- 不要用
toString()结果直接入库或外发，务必清洗掉连字符、转小写、校验长度 - 避免在高并发下单场景中仅依赖 UUID 生成后“查库去重”——UUID 碰撞概率极低（约 2^122 分之一），但查库会拖慢性能，且违背“生成即唯一”的设计初衷
- 如果要求订单号支持数据库索引高效查询，优先选前缀含时间的格式（如时间戳开头），避免纯随机字符串导致 B+ 树频繁分裂
- 测试阶段可用
UUID.randomUUID().getMostSignificantBits()提取长整型做快速 mock，但生产环境仍需完整流程
一个轻量可行的 Java 示例
以下代码生成 22 位、纯字母数字、无连字符、带毫秒精度的订单号：
public static String generateOrderNo() {
long ts = System.currentTimeMillis();
String uuidHex = UUID.randomUUID().toString().replace("-", "");
// 取 uuid 后 12 位 hex + 时间戳后 10 位（避免超长）
return String.format("%s%s",
uuidHex.substring(uuidHex.length() - 12),
String.valueOf(ts).substring(3) // 去掉年份前两位，留 10 位
).toLowerCase();
}
示例输出：c3d8a1b2e4f56789012345（22 位）。它不是完全时间有序，但冲突概率远低于单机每秒百万级生成场景的理论阈值。
