怎么通过 switch 语句的“穿透效应”（Fall-through）处理具有包含关系的业务状态机

先抛一个核心判断：穿透效应（fall-through）不是简化包含关系状态处理的捷径，而是绝不该碰的危险特性。在业务状态机里，每个状态都应该有明确的进入条件、执行逻辑和退出边界，状态迁移必须显式可控——fall-through 恰恰违背了这些原则。

说得更直白些：拿 fall-through 来表达“已发货隐含已支付”这样的状态包含关系，本质上是在把语义层级的依赖当成执行路径的自然延续。这不是靠顺序执行几个 case 就能解决的问题——它会跳过前置条件检查（比如支付校验），也区分不了“本该进入该状态”和“漏了 break 被迫执行”这两种截然不同的情况。更麻烦的是，一旦业务中间加了新状态（比如“已通知物流”），整条穿透链就可能瞬间失效或错位，而静态分析工具根本识别不了这种“语义包含”，只会当作普通的逻辑错误来报警。

为什么不能用 fall-through 表达“包含关系”

所谓“包含关系”——比如“已发货”隐含“已支付”，“已完成”隐含“已发货”和“已支付”——本质是状态语义之间的层级依赖。fall-through 强制顺序执行下一个 case 的代码，但：

• 它不检查前置条件是否真正满足（比如跳过支付校验直接执行发货逻辑）
• 无法区分“本该进入该状态”和“因漏 break 被迫执行”
• 一旦新增中间状态（如加一个“已通知物流”），整个穿透链就失效或错位
• 静态分析工具无法识别这种“语义包含”，只会当普通逻辑错误警告

说白了，这不是靠代码顺序就能模拟出来的关系——应该是配置层面的声明，而不是执行层面的硬连。

正确表达状态包含关系的三种做法

结构化方式处理语义依赖，远好过靠执行顺序去碰运气：

• 状态校验函数链：每个状态的进入函数（如 onEnterShipped()）内部主动调用前置状态检查（assertPaid()、ensureOrderValid()），失败则拒绝迁移并报错。逻辑清晰，测试可覆盖。
• 状态继承枚举设计：用类型系统表达层级——例如定义 enum PaymentStatus { UNPAID, PAID } 和 enum ShippingStatus { NOT_SHIPPED, SHIPPED }，主状态机通过组合字段（order.paymentStatus + order.shippingStatus）判断整体语义，而非靠单个 enum 穿透。
• 状态迁移白名单表：用二维表或 Map 显式声明允许的迁移路径——比如 allowedTransitions.get(CREATED).contains(PAID) 返回 true，但 allowedTransitions.get(CREATED).contains(SHIPPED) 为 false。包含关系由配置驱动，不靠代码执行顺序，维护和审核都更直观。

唯一可接受的 fall-through 场景（极少见）

这种事真有例外吗？有，但仅限于底层协议解析或硬件寄存器映射这类对性能极度敏感、且状态值本身呈连续整数序列的场景。比如：

switch (register_value) {  case 0x00: // idle  case 0x01: // warming_up  case 0x02: // ready    set_green_led();    break;  case 0x03: // error    set_red_led();    break;}

这种写法能成立需要满足几个硬条件：值连续、语义同构、无副作用、不涉及业务规则判断。业务状态机几乎从不满足这些条件——所以见到 fall-through 先别想着“省代码”，问清楚上下文再说。

替代 fall-through 的清晰状态流转模式

把“包含”转化为“检查+动作”，主 switch 其实只该做三件事：

• 根据当前状态和事件，查表或判断是否允许迁移
• 调用目标状态的 enter() 方法（该方法内自行验证前置条件）
• 原子更新状态变量，并触发对应钩子（onExitOld() → onEnterNew()）

这样一来，“已发货必须已支付”就是 onEnterShipped() 内部一行清晰的校验，而不是靠 case PAID 穿透到 case SHIPPED 来“顺便执行”。逻辑归属明确，测试可单独覆盖，新增状态也不会打乱现有流程——这才是业务状态机该有的样子。