直接用if-else或switch处理状态流转易出错，因状态超3个、事件超5种时逻辑失控；枚举类应封装状态行为并显式声明转移规则，每个常量自主实现transition()方法，终态不重写即抛AbstractMethodError，确保编译期约束与非法转移早暴露。
为什么直接用 if-else 或 switch 处理状态流转容易出问题
状态机逻辑一旦超过 3 个状态、5 种事件，硬编码的 if-else 或 switch 就会迅速失控：新增状态要改多处、漏掉某个 case 编译不报错、状态合法性无法在编译期约束。枚举类天然适合表达“有限、确定、互斥”的状态集合，但关键不在“定义状态”，而在“封装状态行为”和“显式声明转移规则”。
Enum 中定义 transition() 方法并返回自身类型
让每个枚举常量自己决定：收到某个事件后，能变成哪个状态？不能就抛异常，而不是静默忽略。这比把所有转移逻辑堆在外部方法里更内聚、更易测试。
示例（简化版订单状态机）：
public enum OrderStatus {
CREATED {
@Override
public OrderStatus transition(Event event) {
if (event == Event.PAY) return PAID;
throw new IllegalStateException("Cannot " + event + " from " + this);
}
},
PAID {
@Override
public OrderStatus transition(Event event) {
if (event == Event.SHIP) return SHIPPED;
if (event == Event.CANCEL) return CANCELLED;
throw new IllegalStateException("Cannot " + event + " from " + this);
}
},
SHIPPED, CANCELLED;
public abstract OrderStatus transition(Event event);
public enum Event { PAY, SHIP, CANCEL }
}
注意点：
-
SHIPPED和CANCELLED没重写transition()，意味着它们是终态——调用时直接抛AbstractMethodError，比返回null或默认值更早暴露问题 - 每个枚举实例的
transition()只管自己能响应什么，不查表、不遍历，性能零开销 - 新增状态只需加一个枚举常量 + 实现
transition()，其他地方完全不用动
避免在 Enum 中持有可变状态或复杂业务逻辑
枚举实例是全局单例，如果在 OrderStatus 里塞一个 private int retryCount，所有订单共享这个计数器——这是常见误用。
正确做法：
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 状态机本身只负责“当前是什么状态”“能变成什么状态”，不负责“为什么变”“变完干啥”
- 具体业务动作（如扣库存、发消息）应该放在外部服务类中，根据
fromState.transition(event)的结果触发对应处理 - 需要记录上下文（比如取消原因、支付渠道）必须由调用方传入，不要试图塞进枚举字段
测试状态转移规则时别只测“能走通”，更要测“不该走通的被拦住”
光验证 CREATED.transition(PAY) == PAID 不够。真正容易出 bug 的是那些非法转移，比如 SHIPPED.transition(PAY) 应该明确失败。
建议写断言：
assertThrows<illegalstateexception>(() -> SHIPPED.transition(PAY));</illegalstateexception>
另外注意：Enum 的 values() 是按声明顺序返回的，如果转移逻辑依赖顺序（比如做数组索引），务必加注释或用 @SuppressWarnings("ArrayToString") 显式标记，否则重构时删/挪了枚举常量位置，行为就变了。
状态机的边界比看起来更窄：它只管“状态之间是否允许跳转”，而“跳转是否合法”（比如库存是否充足）得交由业务校验层判断。混淆这两层，枚举就会慢慢变成难以维护的瑞士军刀。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
