订单状态流转混乱源于状态判断与业务动作耦合，应采用状态模式：每个状态独立成类，通过多态响应操作并返回目标状态标识；状态迁移由集中式状态机校验，订单统一处理持久化与状态更新。
订单状态流转为什么总在 if-else 里越写越乱
因为状态判断逻辑和业务动作耦合太紧：比如 if (status == "paid") { sendGoods(); } else if (status == "shipped") { notifyUser(); }，每加一个状态、每改一个流转规则，都要翻出所有分支挨个补条件——更糟的是，不同状态能执行的操作还不一样（比如“已取消”不能发货，“已完成”不能退款），硬塞进一个函数里就变成一堆 if (status == ...) && canOperate(...) 嵌套判断。
把每个状态抽成独立类，用多态代替条件跳转
核心是让每个状态自己回答两个问题：“我能响应什么操作？”和“我响应后变成什么新状态？”。比如 PaidOrderState 类里只放 ship() 方法，它内部直接返回 new ShippedOrderState()；而 CancelledOrderState 的 ship() 方法则抛出 IllegalStateException("已取消的订单不能发货")。
- 订单实体（
Order）只持有一个currentState引用，所有操作都委托给它：order.ship()实际调用的是当前状态对象的ship() - 状态切换不靠外部赋值，而是由当前状态对象返回新状态实例，
Order再更新引用 - 避免在状态类里访问订单的私有字段——通过构造时传入必要上下文（如
orderId、paymentId），或定义只读接口（如getAmount()）供状态类调用
状态迁移规则必须集中管控，别散落在各个状态类里
光靠状态类自己决定“下一步是谁”，容易导致非法流转（比如从 “created” 直接跳到 “completed”）。真正可靠的方案是引入状态机配置：
- 用一张表或枚举映射定义合法转移：
ALLOWED_TRANSITIONS.get("paid").contains("shipped") == true - 在
Order的操作方法里先校验：if (!stateMachine.canTransition(currentState, targetState)) throw new InvalidStatusTransitionException(...) - 状态类的
ship()方法不再返回新状态，而是返回目标状态标识（如"shipped"），由订单统一做校验和切换——这样校验逻辑不重复，新增状态也不用改所有类
警惕数据库持久化时的状态字段同步问题
状态对象是内存中的，但订单状态通常要落库。如果只更新内存状态却不持久化，重启后就丢失了。常见错误是：在 ShippedOrderState.ship() 里只改了内存状态，忘了调用 orderRepository.updateStatus(orderId, "shipped")。
- 推荐把持久化交给
Order本身：状态类只负责逻辑判断和返回目标状态标识，Order.ship()在校验通过后，先调用状态对象获取目标标识，再更新 DB，最后才替换currentState - 避免在状态类里注入 DAO 或 Repository——这会让状态类承担不该有的职责，也破坏了测试隔离性
- 如果用 JPA，注意
@Enumerated存状态枚举时，枚举名变更会导致历史数据失效；建议用字符串字段存状态码，并在状态工厂中做映射
状态模式不是银弹。当状态数少于 4 个、流转极其简单时，硬编码反而更直观；但一旦出现“部分状态支持 A 操作、部分支持 B、还有几个组合约束”，就该立刻拆——否则下个接手的人会在第 17 层嵌套 if 里，对着 if (status != "cancelled" && status != "refunded" && !isExpired()) 发呆。
