4. 状态机核心概念

在OMS订单系统中，订单从创建到完结并不是一条直线，而是一张由状态、事件和规则共同编织的“行为网络”。理解状态机的七个核心概念，是设计可维护订单生命周期的基础。本节将逐一拆解这些概念，并说明它们如何协同工作。

一、核心原理：七个概念的定义与关系

状态（State）是订单在某一时刻所处的稳定情形，例如“待支付”“已支付”“已发货”“已完成”。状态具有持续性，不会自行改变，必须由事件触发迁移。

事件（Event）是来自外部或内部的一次刺激，例如用户点击“支付”、仓库回传“出库成功”、超时定时器触发“支付超时”。事件是状态迁移的驱动力。

动作（Action）是迁移过程中执行的具体行为，例如扣减库存、发送短信、写入日志。动作可以绑定在进入状态、退出状态或迁移本身上。

转移（Transition）描述“从源状态到目标状态”的完整路径，通常写作“源状态 + 事件 + 守卫条件 → 目标状态 + 动作”。

守卫条件（Guard）是迁移能否发生的布尔判断，例如“库存充足”“支付金额等于订单金额”。守卫为假时，事件被忽略或转入异常分支。

终态（Final State）表示订单生命周期的结束，如“已完成”“已取消”。进入终态后不再接受任何迁移事件。

子状态与分层状态机用于管理复杂状态。例如“已支付”可细分为“待审核”“审核通过”“审核拒绝”；分层状态机允许子状态继承父状态的迁移，减少重复定义。

二、方法流程：从业务规则到状态机模型

将OMS订单业务转化为状态机，建议按以下步骤推进：

1. 枚举状态：列出订单所有稳定情形，区分主状态与子状态。
2. 识别事件：梳理用户操作、系统回调、定时任务三类事件源。
3. 定义转移：为每个状态列出可接受事件及目标状态。
4. 补充守卫：为关键迁移增加金额、库存、权限等校验。
5. 绑定动作：明确迁移前后需要执行的副作用。
6. 标记终态：确定哪些状态不可再迁移。
7. 分层优化：将重复迁移上提到父状态，形成分层结构。

下面是一个简化的订单状态迁移配置片段，使用JSON描述“待支付”状态下的迁移规则：

{
  "state": "PENDING_PAYMENT",
  "transitions": [
    {
      "event": "PAY_SUCCESS",
      "guard": "amountMatched && stockReserved",
      "target": "PAID",
      "actions": ["deductStock", "sendPayNotify"]
    },
    {
      "event": "PAY_TIMEOUT",
      "guard": "now > expireTime",
      "target": "CANCELLED",
      "actions": ["releaseStock", "refundCoupon"]
    }
  ]
}

三、案例场景：订单支付与超时取消

以“待支付”订单为例，用户支付成功事件触发迁移到“已支付”，守卫条件校验金额与库存；若超过30分钟未支付，定时器事件触发迁移到“已取消”，并执行释放库存、退回优惠券等动作。若支付回调重复到达，守卫条件中的“当前状态必须为待支付”可防止重复扣减。

再看分层状态机的典型场景：“已支付”作为父状态，包含“待审核”“审核通过”“审核拒绝”三个子状态。无论处于哪个子状态，收到“用户申请退款”事件都应迁移到“退款中”。若把该迁移定义在父状态上，三个子状态自动继承，无需重复配置。

四、误区与复盘：常见设计陷阱