2. 状态机基础理论
在聚合支付系统中，一笔交易从创建到最终完成（或失败），会经历多个明确的状态阶段。有限状态机（FSM）是描述这种状态流转最严谨的数学模型。本节将深入剖析 FSM 的四大核心要素：状态、事件、转移和动作。
2.1 有限状态机（FSM）核心概念
有限状态机是一个抽象的计算模型，它在任意时刻只能处于有限个状态中的一个。当接收到外部事件时，它会根据预定义的规则从当前状态转移到下一个状态，并在转移过程中执行特定的动作。FSM 是支付系统状态管理的基础，确保了交易流程的确定性和安全性。
FSM 的数学定义： 一个 FSM 可以表示为五元组 (S, E, T, s₀, A)，其中 S 是有限状态集合，E 是有限事件集合，T 是转移函数，s₀ 是初始状态，A 是动作集合。
2.2 四要素详解
2.2.1 状态（State）
状态是 FSM 中最基本的元素，它代表了系统在某个特定时刻的稳定条件或模式。在聚合支付系统中，一个交易的状态必须是明确且互斥的。
- 确定性：系统在任何时刻只能处于一个状态。
- 有限性：所有可能的状态构成一个有限的集合。
- 持久性：状态会持续存在，直到被某个事件改变。
| 支付状态示例 | 状态描述 | 业务含义 |
|---|---|---|
| INIT | 初始状态 | 交易订单已创建，尚未发起支付 |
| PAYING | 支付中 | 已向渠道发起支付请求，等待异步结果 |
| SUCCESS | 支付成功 | 渠道明确返回成功，资金已扣减 |
| FAILED | 支付失败 | 渠道返回失败或超时未收到成功通知 |
| CLOSED | 已关闭 | 交易超时或用户主动取消 |
2.2.2 事件（Event）
事件是触发状态转移的外部输入或内部信号。在支付系统中，事件通常来自用户操作、渠道回调或系统定时器。
- 外部事件：用户点击“提交订单”、支付渠道返回“支付成功”通知。
- 内部事件：系统定时器触发“超时检查”、风控系统触发“交易拦截”。
- 事件携带数据：事件通常附带上下文信息，如支付金额、渠道流水号、错误码等。
设计要点： 事件命名应使用过去时态（如 PaymentReceived、TimeoutOccurred），表示该事件已经发生，这样更符合领域驱动设计（DDD）的实践。
2.2.3 转移（Transition）
转移定义了 FSM 从一个状态到另一个状态的路径。一个完整的转移由 源状态、触发事件、守卫条件 和 目标状态 组成。
// 转移的伪代码表示
Transition {
from: "PAYING" // 源状态
on: "PaymentSuccess" // 触发事件
guard: amount > 0 // 守卫条件（可选）
to: "SUCCESS" // 目标状态
action: "updateBalance" // 执行动作
}转移的合法性由状态转移表严格定义，任何未定义的转移都会被拒绝，从而保证系统的健壮性。
2.2.4 动作（Action）
动作是在状态转移过程中执行的原子操作。动作是 FSM 产生“副作用”的地方，例如更新数据库、发送消息、调用外部服务等。
- 入口动作（Entry Action）：进入某个状态时执行，如记录状态变更日志。
- 出口动作（Exit Action）：离开某个状态时执行，如释放资源锁。
- 转移动作（Transition Action）：在转移过程中执行，如调用支付网关。
2.3 状态机类型对比
| 类型 | 特点 | 适用场景 | 复杂度 |
|---|---|---|---|
| Mealy 机 | 输出（动作）依赖于当前状态和输入事件 | 实时响应要求高的场景，如支付网关适配层 | 中等 |
| Moore 机 | 输出（动作）仅依赖于当前状态 | 状态与行为强关联的场景，如交易状态管理 | 较低 |
| 分层状态机 | 支持状态嵌套，子状态继承父状态行为 | 复杂支付流程，如退款、对账等子流程 | 较高 |
常见误区： 初学者容易将“动作”与“状态”混淆。例如，“发送请求”是一个动作，而不是一个状态。状态应该是“等待响应”（WAITING_RESPONSE），而不是“发送中”（SENDING）。正确的状态建模是支付系统稳定性的基石。
2.4 状态机在支付系统中的价值
- 确定性： 所有可能的状态流转都被显式定义，不存在“未定义”的路径。
- 可追溯性： 每个状态变更都对应一个事件和动作，便于审计和排错。
- 安全性： 非法转移（如从 INIT 直接到 SUCCESS）会被状态机拒绝，防止数据不一致。
- 可维护性： 状态和转移的集中管理，使得业务逻辑变更时只需修改状态机配置，无需改动大量业务代码。