Java枚举实现状态机，高效组织OOP逻辑

Java枚举通过为每个常量重写抽象方法（如nextState(Event)）封装状态转移逻辑，避免if-else或switch分散维护；需传入不可变Context处理条件转移，序列化时须用@JsonCreator/@JsonValue显式控制。

Java枚举里怎么写状态转移逻辑

直接在 enum 里定义状态，每个枚举常量自带行为，比用一堆 if-else 或 switch 去判断状态再调用不同方法更紧凑、更难出错。关键是把「当前状态能响应什么事件」「响应后变成什么状态」封装进枚举自身。

常见错误是把状态转移写成静态方法或外部工具类，结果状态和行为脱节，新增状态时容易漏改转移规则。

• 每个枚举常量重写抽象方法（比如 nextState(Event event)），返回下一个 State
• 避免在枚举中持有可变状态（如 private int count），枚举实例是全局共享的，多线程下会互相污染
• 如果转移逻辑复杂，可以委托给内部私有方法，但别暴露出去——枚举对外只该暴露「我能处理什么」和「处理完去哪」

enum OrderState {
    CREATED {
        @Override
        OrderState nextState(Event e) {
            return switch (e) {
                case PAY -> PAID;
                case CANCEL -> CANCELLED;
                default -> this;
            };
        }
    },
    PAID {
        @Override
        OrderState nextState(Event e) {
            return switch (e) {
                case SHIP -> SHIPPED;
                case REFUND -> REFUNDED;
                default -> this;
            };
        }
    },
    // ... 其他状态
    ;
    abstract OrderState nextState(Event e);
}

为什么不用 switch + enum 常量做状态机

纯 switch 拆分状态逻辑，看似简单，实际会让状态规则散落在各处，每次加新状态都得翻遍所有 switch 块补 case，漏一个就导致运行时跳到默认分支、行为异常。

更隐蔽的问题是：状态合法性校验被动。比如「已发货订单不能退款」这种约束，在 switch 里只能靠注释提醒，编译器不拦；而枚举内建转移逻辑，非法事件自然不会返回目标状态，调用方拿到 null 或抛 IllegalArgumentException 都更容易暴露问题。

• switch 方式下，状态变更和业务动作（如扣库存、发消息）常混在一起，难以单独测试状态流转
• 枚举方式天然支持「状态即类型」，比如可以声明 Map> 绑定每种状态下的专属动作
• JVM 对枚举 switch 有优化，但那是字节码层面的事；对人来说，可维护性才是瓶颈

枚举状态机如何应对「带条件的状态转移」

真实业务里，状态是否能转，往往取决于上下文数据，比如「只有支付金额 > 100 才允许升级为 VIP 状态」。枚举本身不能访问外部变量，所以不能把条件判断全塞进 nextState()。

正确做法是让转移方法接收必要上下文参数，并由调用方保证传入有效值；枚举只负责「给定输入，确定输出」，不负责校验输入合法性。

• 函数签名建议为 nextState(Event e, Context ctx)，其中 Context 是不可变数据载体（如 record）
• 避免在枚举里调用数据库或远程服务——状态机要轻量、确定、无副作用
• 如果条件分支太多，考虑把部分判断提到上层，只把「确定性转移」留给枚举，比如先判断金额是否达标，再调用 PAY.nextState(e)

序列化和反序列化时枚举状态机容易崩在哪

用 Jackson 或 JSON 库序列化含枚举状态的对象时，如果没配好，会把整个枚举对象序列化成完整字段（包括方法），或者反序列化失败报 InvalidDefinitionException。

根本原因是枚举的反序列化依赖其名称（name()），而不是 toString() 或自定义字段。一旦前端传的是 "paid" 而不是 "PAID"，就会找不到对应常量。

• 务必用 @JsonCreator + @JsonValue 显式控制序列化行为
• 不要重写 toString() 来改变序列化输出，Jackson 默认不认这个；用 @JsonProperty("paid") 标在常量上也不行，得走 @JsonCreator 工厂方法
• Spring Boot 项目里，可以在配置中全局启用 DeserializationFeature.READ_ENUMS_USING_TO_STRING，但不如显式控制来得可靠

最稳妥的写法是在枚举里加一个静态工厂方法：

@JsonCreator
public static OrderState from(String name) {
    return Stream.of(values())
        .filter(s -> s.name().equalsIgnoreCase(name) || s.getAlias().equals(name))
        .findFirst()
        .orElseThrow(() -> new IllegalArgumentException("Unknown state: " + name));
}

状态机不是越“全自动”越好，关键路径上的约束、边界检查、日志埋点，还是得由调用方主动做。枚举只是把「状态之间谁连谁」这件事，从代码注释和人脑记忆里，搬进了编译器能检查的类型系统里。