推荐用时间戳（13位）+毫秒内序列号（3-5位）+机器/进程标识（2-4位）组合生成流水号，兼顾唯一性、可读性、时间可追溯性与顺序性；避免直接拼接currentTimeMillis()和UUID。
单纯用 System.currentTimeMillis() 或 UUID 单独生成业务流水号，都存在缺陷：前者在高并发下易重复，后者太长、无序、不易排查。两者结合可以兼顾唯一性、可读性、时间可追溯性和一定顺序性——但要注意不是简单拼接，关键在于设计结构和规避陷阱。
核心思路：时间戳做前缀 + 有序/可控的后缀
UUID 全局唯一但随机性强、长度固定（32位十六进制+4横线），不适合直接作流水号；currentTimeMillis() 精确到毫秒，但在同一毫秒内多线程调用会重复。因此推荐以时间戳为基底，用轻量方式补充“毫秒内序号”或“机器标识”，再选择性融合 UUID 的部分信息（如 node ID 或随机段），而非整个 UUID。
- ✅ 推荐结构：时间戳（13位） + 毫秒内序列号（3-5位） + 机器/进程标识（2-4位）
- ⚠️ 不推荐：
System.currentTimeMillis() + "-" + UUID.randomUUID().toString()—— 过长（约36字符）、含横线和字母，不便于日志检索、数据库索引、前端展示 - ? 替代方案：取 UUID 的 leastSignificantBits（8字节）转为紧凑的 12~14 位 Base32 或数字字符串，仅作“随机扰动因子”，不暴露完整 UUID
轻量安全的实现示例（无外部依赖）
以下代码在单 JVM 进程内高效生成近似全局唯一的流水号（跨 JVM 需额外加机器号或服务实例 ID）：
public class BusinessSeqGenerator {
private static final long START_EPOCH = 1704067200000L; // 自定义起始时间（2024-01-01）
private static final AtomicInteger seqInMs = new AtomicInteger(0);
private static final int MAX_SEQ = 999; // 每毫秒最多 999 个
private static final String MACHINE_ID = "01"; // 可从配置或 IP 哈希生成，2位足够
<pre class="brush:php;toolbar:false;">public static String generate() {
long currentMs = System.currentTimeMillis() - START_EPOCH;
int seq = seqInMs.incrementAndGet() % (MAX_SEQ + 1);
if (seq == 0) {
// 溢出时等待下一毫秒（或丢弃重试，视业务容忍度而定）
try { Thread.sleep(1); } catch (InterruptedException e) { }
return generate();
}
return String.format("%013d%03d%s", currentMs, seq, MACHINE_ID);
}}
生成结果形如：123456789012300101（13位时间偏移 + 3位序列 + 2位机器号），共18位纯数字，支持数据库 B-tree 索引、按时间范围查询、肉眼可大致判断生成时段。
如需更强跨进程唯一性，可引入 UUID 片段
若系统部署在多台机器且无法统一分配 machineId，可用 UUID 的低 64 位哈希压缩为 4~5 位数字，作为“轻量节点指纹”：
- 取
UUID.randomUUID().getLeastSignificantBits() - 对其做
Math.abs(hash) % 10000得到 0–9999 的 4 位数（补零） - 拼入末尾替代 MACHINE_ID，例如：
timeSeq + String.format("%04d", nodeId) - ⚠️ 注意：不能用
UUID.toString()全量，避免横线、字母、长度失控
实际使用提醒
业务流水号本质是“在特定上下文里不重复 + 易维护”，不必强求密码学级唯一：
- 数据库务必对流水号字段加 唯一索引，作为最终兜底
- 避免在分布式事务中依赖生成逻辑的“绝对唯一”，应配合幂等键（如订单号+操作类型）
- 若审计要求严格，可在生成后记录到独立日志表，关联时间、服务名、traceId
- 不建议把 UUID 全量混入流水号——它不携带时间信息，破坏排序性，也增加存储和传输开销
