使用状态模式有哪些常见误区？

简化版

状态模式常见误区包括：只把 if else 搬到状态类里、状态迁移规则分散且无状态图、状态对象持有请求级可变数据、忽略持久化和并发控制、非法迁移处理不统一，以及简单场景过度设计。

详细版

常见问题主要有：

状态类职责不清，仍然判断大量其他状态；
没有状态图，迁移规则散落在代码里；
直接让外部随意设置状态；
只改内存状态，不更新数据库；
忽略并发状态迁移；
支付回调、消息重复等幂等问题没处理；
非法操作随意抛异常或静默忽略；
状态类数量过多但缺少治理；
把复杂状态机硬写成状态模式；
简单状态判断过度设计。

面试时可以强调：状态模式不是状态字段的包装器。好的状态模式要有清晰状态图、合法迁移规则、统一错误处理和工程上的持久化、并发、幂等保障。

完整版教学

一、误区一：只是把 if else 搬家

有些代码表面上用了状态模式，但状态类内部还是这样：

if (context.getStatus() == WAIT_PAY) {
    ...
} else if (context.getStatus() == PAID) {
    ...
}

这只是把条件判断从 Context 搬到 State，并没有真正封装状态行为。

好的状态类应该主要关心自己状态下的行为，不应该频繁判断其他状态。

二、误区二：没有状态图

状态模式一定要先梳理状态图。

如果没有状态图，代码里的迁移会变得很散：

这个状态类能跳到 A
那个状态类能跳到 B
另一个方法又能跳到 C

最后没人能确定完整生命周期是什么。

至少应该明确：

有哪些状态；
有哪些事件；
哪些迁移合法；
哪些迁移非法；
迁移时执行什么动作。

三、误区三：外部可以随意设置状态

如果业务代码到处能写：

order.setStatus(FINISHED);

状态模式基本就失控了。

状态变化应该通过业务操作触发，比如：

order.pay();
order.ship();
order.confirmReceive();

状态迁移必须经过规则校验，而不是外部随意改字段。

四、误区四：只改内存状态

示例代码里常写：

context.setState(new PaidState());

但真实系统里还要更新数据库。

如果只改内存状态：

应用重启状态丢失；
多实例之间状态不一致；
查询订单时仍然是旧状态；
并发请求无法控制。

所以状态模式落地时必须考虑持久化。

五、误区五：忽略并发和幂等

状态迁移经常发生并发。

比如：

用户点击取消订单；
支付回调同时到达；
消息队列重复投递；
管理后台手动修改状态。

如果没有乐观锁、条件更新、幂等表或状态变更流水，就可能出现状态错乱。

状态模式不能自动解决这些工程问题。

六、误区六：非法迁移处理混乱

有的状态类抛异常，有的返回 false，有的静默忽略，有的直接改成失败状态。

这种处理方式会让上层很难统一响应。

建议统一定义非法迁移处理策略：

返回统一错误码；
抛统一业务异常；
记录状态迁移失败日志；
对重复事件做幂等成功处理。

特别是支付回调这类场景，重复事件不一定是错误，可能应该幂等返回成功。

七、误区七：复杂流程只靠状态模式硬撑

如果状态数量很多，事件很多，还涉及守卫条件、并行动作、补偿、超时、人工干预，单纯状态模式会很难维护。

这时应该考虑：

状态机框架；
工作流引擎；
状态迁移表；
事件驱动架构；
流程编排服务。

状态模式适合组织状态行为，不一定适合治理大型流程。

八、误区八：简单问题过度设计

如果只是：

if (enabled) {
    start();
} else {
    stop();
}

没必要拆成 EnabledState 和 DisabledState。

设计模式要解决真实复杂度，不要为了显得高级而制造类爆炸。

九、用迁移矩阵和并发测试审查实现

3 个状态×4 个事件共有 12 个组合，若只允许 5 条迁移，测试应至少覆盖 5 条合法边和 7 条非法边。

state-event matrix -> legal transitions -> idempotent repeats -> concurrent CAS tests

状态题的正确性落在“当前状态 + 事件 + 守卫条件 → 目标状态”这一条边上，而不是类数量上。每条边都要说明持久化原子性、重复事件结果和副作用触发时机，非法边则必须得到稳定且可观测的拒绝。

十、迁移一致性、幂等与并发验证

检查维度	应确认的内容
机制正确性	状态模式的可靠性来自显式迁移和工程约束，不来自把 if-else 分散到类里。
适用边界	状态变化后的通知、日志和外部调用要明确事务边界；失败补偿不能藏在状态 setter 里。
测试证据	并发发送相同与冲突事件，验证乐观锁、幂等键、重试和最终状态日志
工程代价	重点评估状态数、迁移边数、一次迁移的数据库竞争，以及新增状态对完整迁移矩阵的影响

易错点：状态模式的可靠性来自显式迁移和工程约束，不来自把 if-else 分散到类里。

十一、常见误区与追问

误区：只测试每个状态的成功路径就够了。 非法事件、重复事件和并发迁移更容易暴露生产问题，必须纳入矩阵测试。
误区：把状态码换成状态类就自动消除了所有条件判断。 状态对象只能封装状态相关行为；持久化、并发控制、权限和跨聚合规则仍需显式设计。
追问：如何识别只是把 if-else 搬家？ 若每个状态类仍按所有状态码分支，或 Context 每次先判断状态再决定调用哪个方法，说明委托边界没有建立。
追问：非法状态迁移应该静默忽略吗？ 不应该；应返回明确业务错误并记录当前状态、事件和聚合标识，重复事件则按幂等规则单独处理。
追问：状态模式最容易漏掉哪类测试？ 非法迁移、重复事件和并发竞争；它们比单线程成功路径更能证明状态模型可靠。

十二、加强记忆

状态模式的坑可以记成“别搬 if else，先画状态图，别让外部乱改状态，别忘落库并发和幂等”。它适合状态驱动行为，但复杂流程要上状态机，简单判断别过度设计。状态模式写得好，是清晰；写过头，就是一堆状态类迷宫。

简化版

详细版