订单状态机应显式建模状态、事件、动作和转移规则，用枚举定义状态与事件确保类型安全，集中管理转移规则并校验合法性，状态变更需原子性执行、事务一致且可追溯。
订单状态机的核心设计原则
状态机不是简单用if-else或switch控制流程，而是把“状态”“事件”“动作”“转移规则”显式建模。Java中推荐采用有限状态机（FSM）思想：每个订单有唯一当前状态，只响应合法事件，触发预定义动作后转移到新状态，非法操作直接拒绝——这能避免状态错乱、重复处理、脏数据等常见问题。
用枚举定义状态与事件更安全可靠
避免用String或int表示状态，用枚举可编译期校验、语义清晰、易于扩展：
// 状态枚举
public enum OrderStatus {
CREATED, PAID, SHIPPED, DELIVERED, CANCELLED, REFUNDED
}
// 事件枚举
public enum OrderEvent {
PAY, SHIP, DELIVER, CANCEL, REFUND
}
状态转移规则建议集中管理
不把逻辑散落在Service方法里，而是用配置化方式定义“什么状态下允许发生什么事件”。例如用Map嵌套结构：
private static final Map
OrderStatus.CREATED, Set.of(OrderEvent.PAY, OrderEvent.CANCEL),
OrderStatus.PAID, Set.of(OrderEvent.SHIP, OrderEvent.CANCEL, OrderEvent.REFUND),
OrderStatus.SHIPPED, Set.of(OrderEvent.DELIVER, OrderEvent.REFUND),
OrderStatus.DELIVERED, Set.of(OrderEvent.REFUND)
);
执行前校验：if (!TRANSITION_RULES.getOrDefault(currentStatus, Set.of()).contains(event)) throw new IllegalStateException("非法状态转移")
立即学习“Java免费学习笔记（深入）”；
状态变更需保证原子性与可追溯
一次状态变更应是一次完整事务：
- 用数据库行锁（如SELECT ... FOR UPDATE）或乐观锁（version字段）防止并发修改
- 状态更新与业务动作（如扣库存、发消息）必须在同一个事务内完成
- 记录状态变更日志表，包含order_id、from_status、to_status、event、operator、create_time
- 关键动作失败时，状态不更新，避免“状态已变但业务未执行”的不一致
