业务状态机用switch实现适合轻量场景，核心是“当前状态+事件→下一状态+动作”，需显式处理非法转移、保证原子性、避免漏break，并在状态多或需动态配置时改用状态模式等方案。
业务状态机用 switch 语句实现，核心是把“当前状态 + 事件”映射为“下一个状态 + 后续动作”。它适合状态数不多、逻辑相对线性、不强调可扩展性的轻量场景。
用 switch 模拟状态转移
典型做法是：在处理某个业务动作（如订单支付）时，先读取当前状态，再根据事件类型（如“用户点击支付”）用 switch 分支决定能否执行、更新为何种新状态，并触发对应副作用（如发通知、扣库存）。
- 状态通常用枚举或字符串表示，比如
ORDER_CREATED、ORDER_PAID、ORDER_SHIPPED - 每个
case对应一个当前状态，内部再判断事件（可用嵌套if或二次switch） - 必须显式处理非法转移，例如从
ORDER_SHIPPED再次触发“支付”，应拒绝并报错
一个简化的订单状态机示例（Java 风格）
// 假设 event 是触发的动作，order 是当前订单对象
switch (order.getStatus()) {
case ORDER_CREATED:
if ("pay".equals(event)) {
order.setStatus(ORDER_PAID);
deductInventory(order);
sendPaymentSuccessMsg(order);
} else if ("cancel".equals(event)) {
order.setStatus(ORDER_CANCELLED);
refundIfNecessary(order);
}
break;
case ORDER_PAID:
if ("ship".equals(event)) {
order.setStatus(ORDER_SHIPPED);
triggerLogistics(order);
}
break;
case ORDER_SHIPPED:
if ("confirm".equals(event)) {
order.setStatus(ORDER_COMPLETED);
closeOrder(order);
}
break;
default:
throw new IllegalStateException("Invalid state: " + order.getStatus());
}
注意事项和常见坑
- 状态变更和副作用要原子化：先改状态再执行动作；若动作失败（如扣库存失败），需回滚状态或进入补偿态，不能留中间脏状态
-
避免漏写 break：尤其多事件共用一个状态分支时，少一个
break就可能意外穿透到下一状态逻辑 - 别把复杂校验塞进 case 里：权限检查、业务规则（如“仅限 24 小时内可取消”）建议提前拦截，保持 switch 体轻量清晰
- 状态定义要唯一且封闭：所有 case 必须覆盖全部合法状态，未列出的状态应抛异常，防止静默忽略
什么时候不该用 switch 实现状态机
- 状态超过 10 个，或转移关系频繁变动——维护成本陡增
- 需要运行时动态配置状态流转（如通过 JSON 定义）
- 不同状态下的行为差异大，涉及大量策略类或回调函数
- 要求支持状态历史追溯、可视化流程图、暂停/恢复等高级能力
这种情况下，更适合用状态模式、专用状态机库（如 Spring StateMachine、Squirrel）或规则引擎。
