3. 状态机核心概念
在支付系统中，订单从创建到最终完成或关闭，会经历一系列明确且不可随意跳跃的阶段。要准确描述并控制这一过程，必须掌握状态机的六个核心概念：状态、事件、动作、转移、守卫条件和终态。它们共同构成支付订单生命周期管理的“语法”，也是后续实现幂等、对账、补偿和风控的基础。
一、核心原理：六个概念如何协同工作
状态是订单在某一时刻的稳定快照，例如“待支付”“支付中”“已支付”“已关闭”。状态必须互斥且可枚举，不能出现“既已支付又已关闭”的模糊描述。事件是触发状态变化的外部或内部信号，如用户点击支付、渠道回调成功、超时定时器到期。动作是状态转移过程中执行的具体业务逻辑，例如扣减库存、写入支付流水、发送通知。转移是“从源状态到目标状态”的有向边，它把事件、守卫条件和动作绑定在一起。守卫条件是转移能否发生的布尔判断，例如“仅当订单金额大于0且未超过支付截止时间”。终态是不能再发生任何转移的状态，如“已完成”“已关闭”“已退款”。
二、方法流程：一次支付回调的完整状态迁移
以“用户支付后渠道异步回调”为例，说明各概念如何落地。订单初始为“待支付”，渠道回调到达时产生事件 PAY_CALLBACK。系统先执行守卫条件：校验签名、核对金额、确认订单当前状态仍为“待支付”。守卫通过后，执行动作：更新订单为“已支付”、写入支付流水、触发履约。若守卫失败，则记录异常并保持原状态，避免重复支付。
事件: PAY_CALLBACK
源状态: PENDING_PAY
守卫条件: signValid == true
&& callbackAmount == orderAmount
&& currentState == PENDING_PAY
动作: updateOrderStatus(PAID)
insertPaymentFlow()
triggerFulfillment()
目标状态: PAID
从工程实现看，推荐把状态、事件、守卫和动作集中配置在状态机定义中，而不是散落在业务代码的 if-else 里。这样订单状态图就是唯一事实来源，新增渠道或调整规则时只需修改配置，降低遗漏和冲突。
三、状态机类型：有限状态机与层次状态机
有限状态机（FSM）是最常用的形式，状态数量有限、转移关系扁平。支付订单的“待支付→支付中→已支付→已退款”就是典型 FSM。它的优点是直观、易测试、易审计；缺点是当状态和事件增多时，转移边会迅速膨胀。
层次状态机（HSM）允许状态嵌套，子状态继承父状态的转移。例如把“支付中”拆分为“渠道路由中”“渠道请求中”“渠道确认中”，它们共享父状态“支付中”的超时事件和取消事件。HSM 能显著减少重复转移，适合复杂支付渠道、多阶段风控和跨境结算场景。
| 对比维度 | 有限状态机 FSM | 层次状态机 HSM |
|---|---|---|
| 状态结构 | 扁平、互不嵌套 | 可嵌套、支持父子状态 |
| 转移数量 | 随状态数快速增长 | 子状态继承父状态转移，数量更少 |
| 适用场景 | 简单支付订单、单渠道 | 多渠道路由、多阶段风控、跨境结算 |
| 实现复杂度 | 低，易上手 | 中高，需要层级解析 |
| 可测试性 | 路径清晰，覆盖容易 | 需覆盖父子状态组合 |
四、案例与场景：支付订单状态图
下图展示了一个精简但完整的支付订单状态机。节点表示状态，箭头表示转移，箭头上的文字表示事件与守卫条件。可以看到“待支付”是初始状态，“已完成”“已关闭”“已退款”是终态，任何进入终态的订单都不再接受新事件。
五、误区与复盘
- 把状态当事件用。例如把“支付成功”既写成状态又写成事件，导致转移定义混乱。正确做法是状态用名词，事件用动词或过去式。
- 忽略守卫条件。渠道重复回调时，若没有“当前状态必须为待支付”的守卫，订单会被重复置为已支付，引发重复履约。
- 终态不终。已关闭订单又被退款事件激活，说明终态定义不严格。终态必须拒绝所有事件，或显式定义“终态到终态”的例外规则。
- 动作放在转移之外。把扣库存写在回调接口里而非状态机动作中，会导致状态与业务副作用不一致，难以补偿。
- FSM 与 HSM 混用无边界。简单订单强行上 HSM 会增加维护成本；复杂多渠道订单用扁平 FSM 则转移爆炸。应按业务复杂度选择。