推荐组合方案：时间戳+机器标识+序列号，如202505201530220010001；其次Snowflake（64位整数编码）及数据库辅助方案（seq_generator表+缓存）；需避坑伪随机、时间回拨、字符混淆等问题。

Java中生成唯一业务编号，核心是兼顾唯一性、可读性、有序性、高性能，不能只靠UUID.randomUUID()——它虽全局唯一但不可读、无序、长度长，不适合订单号、单据号等业务场景。

一、推荐组合方案：时间戳 + 机器标识 + 序列号

这是电商、金融系统最常用的高并发安全方案，例如：202505201530220010001（年月日时分秒 + 机房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交互，且需严格连续/可控格式（如SO2025050001），可用以下方式：

立即学习“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个号，用完再批量续），避免每次请求都查库

四、注意事项与避坑点

别让编号成为系统瓶颈或故障源：

• 禁止在循环里反复调用new Random().nextInt()生成“伪唯一”号——碰撞概率随数量指数上升
• 不用Math.random()或System.nanoTime()单独做主键，它们不具备跨JVM唯一性
• 如果编号要对外展示（如用户订单号），建议避开易混淆字符（0/O, 1/l/I），可采用base32（不含0,O,l,I）或自定义编码字典
• 测试阶段用固定workerId，上线前通过配置中心或启动参数注入真实ID，避免本地跑出一堆相同前缀的“假号”

基本上就这些。选型看场景：高并发选Snowflake类方案，强顺序选DB+缓存，简单内部系统可用时间戳+随机后缀。关键是统一管理生成逻辑，别散落在各Service里硬编码。