一、什么是状态机？为什么 Spring 要专门封装它
1.1 从“if-else 海啸”说起
在任何一个具有多状态的生命周期管理场景中，这种代码非常常见：
if (order.getStatus() == OrderStatus.CREATED) { if (event == Event.PAY) { // 支付逻辑 order.setStatus(OrderStatus.PAID); } else if (event == Event.CANCEL) { // 取消逻辑 order.setStatus(OrderStatus.CANCELED); } } else if (order.getStatus() == OrderStatus.PAID) { if (event == Event.SHIP) { // 发货逻辑 order.setStatus(OrderStatus.SHIPPED); } else if (event == Event.REFUND) { // 退款逻辑 order.setStatus(OrderStatus.REFUNDED); } } // …… 后面还有一堆类似的判断，一旦开始删改就会心生绝望这类「if-else 式」状态管理的弊端非常明显：
状态与转换分散在不同业务 Service 中，持续膨胀的嵌套结构会让维护成本飙升；
每次增加状态或修改转换规则都要在多个地方修改，极易遗漏导致奇怪 Bug；
行为没有与状态强绑定，业务逻辑难以测试和复用。
这就是 Spring Statemachine 要解决的刻骨铭心的痛点。这个框架并非凭空发明一种新的设计模式，而是基于经典的状态模式，通过声明式的配置（注解 / DSL / UML）和高度模块化的组件，让状态和状态之间的流转集中、清晰、可测、可扩展。
Spring Statemachine 是供应用程序开发人员在 Spring 应用程序中使用状态机概念的框架，旨在提供易于使用的扁平单级状态机（简单用例）和分层状态机结构（复杂用例），帮助我们简化状态管理。
1.2 状态机不是什么？搞清两个边界
很多人在初接触 Spring Statemachine 时会追问：它到底是我需要一个重量级工作流引擎（如 Activiti），还是一个与业务无关的通用状态管理库？答案是——Spring Statemachine 是 有限状态机模型（FSM）的具体实现，不需要 BPMN 规范、任务分配、流程变量等复杂概念。它的核心作用是把当前业务中需要的「状态」和「转换」关系严丝合缝地管理起来，保证转换的确定性。
二、核心概念 —— 从名词解析到交互全景
2.1 五大基本要素，看完就能画状态图
任何一个 Spring Statemachine 都围绕以下 5 个核心概念建模，这 5 个概念就是构成整个清晰结构的最小单元
| 概念 | 定义 | 示例 |
| 状态（State） | 对象在生命周期中的阶段 | UNPAY，PAID，SHIPPED |
| 事件（Event） | 触发状态流转的外部刺激 | PAY、SHIP、RECEIVE |
| 转换（Transition） | 源状态与事件 → 目标状态的映射 | PAY 事件：UNPAY → PAID |
| 守卫（Guard） | 转换前校验的布尔条件 | order.amount > 0 才可支付 |
| 动作（Action） | 转换过程中执行的业务逻辑 | 减库存、发送消息、写审计日志 |
这五个要素把整个生命周期拆成最小的可控单元。比如电商系统中一个典型的转换规则如下
public enum OrderStates { UNPAY, WAITING_PAY, PAID, SHIPPED, DONE } public enum OrderEvents { PAY, SHIP, RECEIVE } // 在配置时就会形成：UNPAY 状态下收到 PAY 事件 → PAID 状态2.2 分层设计：Spring Statemachine 源码
如果你只是调用 sendEvent()，可能感觉就是个简单的 Map 映射。但事实上，Spring Statemachine 底层采用了一套清晰的分层架构，这也是它能稳定处理复杂业务的核心所在
客户端层（业务代码所在层）：
业务方调用 stateMachine.sendEvent() 触发。例如：
stateMachine.sendEvent(MessageBuilder
