Java枚举实现状态机的核心是让每个状态自主决定事件响应，通过抽象方法强制各枚举值实现自身转移逻辑，拒绝隐式默认、禁止业务动作嵌入、新增状态仅需三步且不影响现有代码。
Java枚举类实现状态机，核心不是“把状态列出来”，而是让每个状态自己回答：“我收到这个事件，能变成谁？”——用对象化思维把状态当作有行为的主体，而不是被动的数据容器。
状态即对象：每个枚举值自主决定转移逻辑
传统写法把所有判断堆在外部 service 里，比如：
if (status == CREATED && event == PAY) return PAID;
这种代码随状态和事件增多迅速失控。而枚举天然支持为每个常量定制行为：
- 声明抽象方法（如 transition(Event e) 或 approve(Context c)），强制子类实现
- CREATED、PAID 等每个枚举实例用自己的重写逻辑处理事件，不查表、不遍历
- 终态（如 CANCELLED、COMPLETED）可不重写方法，调用时直接抛 AbstractMethodError，编译期就暴露非法操作
转移规则显式化：拒绝隐式默认和静默失败
避免使用 switch + default 分支兜底，或返回 this / null 掩盖问题：
- 每个 transition() 方法只响应它允许的事件，其余一律抛 IllegalStateException，带清晰提示如 “Cannot SHIP from CANCELLED”
- 不依赖 ordinal() 判断顺序，防止重构时调整枚举位置导致逻辑错乱
- 不把业务动作（如发消息、扣库存）塞进枚举里，状态机只管“能不能变”，不变“变了之后做什么”
结构清晰、扩展无痛：新增状态只需三步
当业务需要加一个“待人工复核”状态时：
立即学习“Java免费学习笔记（深入）”；
- 在枚举中添加新常量 AWAITING_REVIEW
- 重写 transition(Event)，明确它接受哪些事件（如 APPROVE、REJECT）
- 其他已有状态、服务类、测试用例完全不用动
警惕常见误用：枚举不是万能容器
枚举实例是全局单例，不适合存可变状态：
- ❌ 不要在枚举里定义 private int retryCount —— 所有订单共享同一计数器
- ❌ 不要让枚举持有复杂业务对象（如 Service 引用），破坏纯状态职责
- ✅ 正确做法：状态流转结果由外部服务根据 fromState.transition(e) 返回值触发对应动作
