推荐组合方案：时间戳+机器标识+序列号，如202405201530220010001；其次Snowflake（64位整数编码）及数据库辅助方案（seq_generator表+缓存）；需避坑伪随机、时间回拨、字符混淆等问题。
Java中生成唯一业务编号，核心是兼顾唯一性、可读性、有序性、高性能，不能只靠UUID.randomUUID()——它虽全局唯一但不可读、无序、长度长，不适合订单号、单据号等业务场景。
一、推荐组合方案：时间戳 + 机器标识 + 序列号
这是电商、金融系统最常用的高并发安全方案，例如：202405201530220010001（年月日时分秒 + 机房ID + 机器ID + 毫秒内序列）。
-
时间戳前缀：保证大致有序、便于数据库索引和排查；建议用
yyyyMMddHHmmss或更紧凑的62进制编码（如System.currentTimeMillis()转base62）减少长度 - 机器/实例标识：避免多节点重复，可用IP后缀、配置的workerId、或ZooKeeper分配的ID；不建议直接用MAC或完整IP（有安全与兼容风险）
- 序列号：同一毫秒内自增，用AtomicLong或RingBuffer（如Twitter Snowflake变种）防锁争用；注意重置逻辑（毫秒变化时归零）
二、轻量级方案：Snowflake及其Java实现
Twitter开源的Snowflake是经典解法，64位整数编码（1位符号 + 41位时间 + 10位机器ID + 12位序列），Java已有成熟封装：
- 用MyBatis-Plus内置的
IdWorker（默认workerId=1，datacenterId=1，需初始化时指定） - 或引入官方Java版（已归档）或更活跃的weixin-java-common中的Snowflake
- 注意：首次启动必须确保系统时间不回拨，否则抛异常；可配“等待回拨恢复”或降级为随机+时间补偿
三、数据库辅助方案（适合低并发或强一致性要求）
当业务允许少量DB交互，且需严格连续/可控格式（如SO2024050001），可用以下方式：
立即学习“Java免费学习笔记（深入）”；
- 单独建一张
seq_generator表，字段：business_type、current_value、step；每次用UPDATE ... SET current_value = current_value + #{step}获取新号 - 配合MySQL的
REPLACE INTO ... SELECT MAX() + 1或Oracle的SEQUENCE.NEXTVAL，但要注意分布式下锁表或性能瓶颈 - 务必加缓存（如Redis预生成100个号，用完再批量续），避免每次请求都查库
四、注意事项与避坑点
别让编号成为系统瓶颈或故障源：
- red">禁止在循环里反复调用new Random().nextInt()生成“伪唯一”号——碰撞概率随数量指数上升
- 不用
Math.random()或System.nanoTime()单独做主键，它们不具备跨JVM唯一性 - 如果编号要对外展示（如用户订单号），建议避开易混淆字符（0/O, 1/l/I），可采用base32（不含0,O,l,I）或自定义编码字典
- 测试阶段用固定workerId，上线前通过配置中心或启动参数注入真实ID，避免本地跑出一堆相同前缀的“假号”
基本上就这些。选型看场景：高并发选Snowflake类方案，强顺序选DB+缓存，简单内部系统可用时间戳+随机后缀。关键是统一管理生成逻辑，别散落在各Service里硬编码。
