1. 状态机基础：有限状态机(FSM)核心概念

有限状态机（Finite State Machine, FSM）是描述系统在有限个状态之间迁移行为的数学模型。在企业审批流中，每一笔单据（如采购订单、报销单）都遵循明确的状态流转规则，FSM 正是构建这种规则骨架的最优工具。

1.1 核心四要素

FSM 由四个基本元素构成，它们共同定义了系统的全部行为边界：

要素	英文	定义	审批流示例
状态	State	系统在某一时刻所处的稳定局面	待审批、审批中、已通过、已驳回
事件	Event	触发状态转移的外部或内部信号	提交申请、审批通过、驳回操作
转移	Transition	从当前状态到下一个状态的路径	待审批 → 审批中（提交事件）
动作	Action	转移发生时执行的业务逻辑	发送通知、更新数据库、记录日志

1.2 四要素的关系模型

状态、事件、转移、动作之间遵循严格的组合规则：当前状态 + 事件 → 转移 → 新状态 + 动作。这种关系可以用以下公式表达：

FSM = (S, E, T, A)
其中：
  S = {s₁, s₂, ..., sₙ}   // 有限状态集合
  E = {e₁, e₂, ..., eₘ}   // 有限事件集合
  T: S × E → S            // 转移函数，定义从当前状态经事件到达目标状态
  A: S × E → Action       // 动作函数，定义转移时执行的业务逻辑

1.3 状态机核心结构图

下图展示了 FSM 四要素之间的静态关系与动态流转路径：

1.4 状态：系统的稳定锚点

状态是 FSM 中最核心的概念，它代表系统在某个时间点的稳定快照。在审批流中，状态必须满足以下特征：

• 有限性：状态数量是确定的、可枚举的。例如审批流通常包含 4~8 个状态，不会无限增长。
• 互斥性：同一时刻系统只能处于一个状态。一张单据不能同时是“待审批”和“已通过”。
• 可观测性：外部系统可以通过查询明确获知当前状态。
• 持久性：状态在数据库中有对应的字段记录，即使系统重启也能恢复。

1.5 事件：状态转移的触发器

事件是推动状态机前进的外部驱动力。在审批流中，事件通常来自用户操作或系统回调：

事件类型	来源	示例	触发条件
用户事件	前端操作	提交申请、审批通过、驳回	用户点击按钮
系统事件	定时器/回调	超时自动审批、第三方回调	时间到达/外部响应
内部事件	状态机自身	进入状态、离开状态	转移完成时自动触发

1.6 转移：状态之间的合法路径

转移定义了状态机允许的演化路径。不是所有状态之间都可以任意跳转，转移必须满足：

• 合法性：转移必须在状态转移表中预先定义，未定义的转移会被拒绝。
• 原子性：转移要么完整执行（新状态+动作），要么完全不执行，不允许中间状态。
• 有向性：转移是单向的，从状态 A 到状态 B 的转移不意味着可以反向。

1.7 动作：转移时的业务逻辑

动作是状态机产生业务价值的环节。当转移发生时，动作按以下顺序执行：

1. 离开动作：离开当前状态前执行（如释放资源）
2. 转移动作：转移过程中执行（如校验数据、更新字段）
3. 进入动作：进入新状态后执行（如发送通知、触发后续流程）

1.8 四要素在审批流中的完整示例

以采购订单审批为例，展示四要素如何协同工作：

状态集合 S = {草稿, 待审批, 审批中, 已通过, 已驳回, 已撤销}
事件集合 E = {提交, 审批通过, 驳回, 撤销, 重新提交}

转移规则示例：
  草稿    + 提交     → 待审批   + 动作：锁定单据、发送审批通知
  待审批  + 审批通过 → 已通过   + 动作：更新库存、生成采购单
  待审批  + 驳回     → 已驳回   + 动作：记录驳回原因、通知申请人
  已驳回  + 重新提交 → 待审批   + 动作：清除驳回记录、重新锁定
  待审批  + 撤销     → 已撤销   + 动作：释放锁定、记录撤销日志

1.9 状态机设计原则

在企业审批流中应用 FSM 时，应遵循以下设计原则：

• 完备性：每个状态都必须定义所有可能事件的响应，未定义的事件应被明确拒绝。
• 可达性：每个状态都应有至少一条从初始状态到达的路径，避免出现“死状态”。
• 可退出性：每个非终态都应有至少一条离开的转移路径，避免系统卡死。
• 无歧义性：同一状态对同一事件只能有一个转移目标，避免运行时冲突。