1. 状态图到底在解决什么问题很多人第一次接触UML状态图是在需求评审或者系统设计文档里看到一堆圆角矩形和箭头觉得这玩意儿就是画着好看、评审时凑页数用的。我刚开始做后端开发那几年也是这么想的直到有一次做一个订单履约系统状态流转逻辑写了两千多行if-else上线后每隔几天就出一个状态错乱的生产事故排查起来像大海捞针才真正意识到状态图的价值。状态图State Diagram本质上是一种描述对象生命周期行为的建模工具。它关注的不是“谁调用谁”也不是“数据怎么流”而是一个对象在它的生命期内会经历哪些状态、在什么条件下从一个状态迁移到另一个状态、迁移时触发什么动作。这个“对象”可以是一个订单、一个支付单、一个工单、一个设备连接、一个用户会话甚至是一个前端页面的交互流程。它解决的核心问题就一个把散落在代码各处的状态判断逻辑提前用一种所有人都能看懂的方式固化下来。产品经理能看懂测试能看懂后端能看懂前端也能看懂。大家在同一个语义平面上讨论“订单从待支付变成已支付到底需不需要经过风控审核这个中间态”而不是等到代码写完才发现产品想的和开发做的根本不是一回事。状态图和流程图的区别经常被混淆。流程图描述的是“做事的步骤”强调的是动作的先后顺序状态图描述的是“对象的状态”强调的是在某个状态下能响应什么事件、响应后跳到哪个状态。举个例子流程图会说“先校验库存再扣减库存再生成订单”状态图会说“订单处于待确认状态时收到库存充足事件则迁移到已确认状态收到库存不足事件则迁移到已取消状态”。前者是过程视角后者是对象视角。两者互补不能互相替代。适合学习状态图的人其实比想象中多。后端工程师用它来设计订单、支付、工单等有明确生命周期的领域对象前端工程师用它来管理复杂页面的交互状态避免出现“加载中又弹了错误提示”这种状态冲突测试工程师用它来推导状态覆盖的测试用例保证每个迁移路径都被验证过产品经理用它来和开发对齐业务规则减少口头沟通的歧义。只要你面对的对象有“状态”这个概念状态图就值得花时间掌握。2. 状态图的四根支柱状态、迁移、事件、动作2.1 状态不只是“当前处于什么阶段”状态在状态图里用圆角矩形表示看起来简单但实际建模时最容易出问题。很多人会把“动作”当成“状态”比如把“发送短信”画成一个状态这就错了——发送短信是一个动作不是对象所处的稳定条件。状态的定义是对象在某个时间段内满足的某种条件或情形。它应该是稳定的、可命名的、有明确语义的。状态分为几种类型。简单状态就是普通的圆角矩形比如“待支付”“已支付”“已发货”。复合状态内部还嵌套了子状态机比如“订单处理中”这个状态内部又分为“库存锁定中”“支付确认中”“物流分配中”三个子状态。复合状态的价值在于分层表达避免一张图铺得太大看不清。历史状态用圆圈里加H表示作用是记住复合状态上次退出时停留在哪个子状态下次进入时直接恢复而不是从头开始。这个在订单超时后重新激活的场景里特别有用。还有一个容易被忽略的概念是入口动作和出口动作。入口动作是进入某个状态时自动执行的动作出口动作是离开某个状态时自动执行的动作。比如进入“已支付”状态时自动发送支付成功通知离开“待支付”状态时自动释放库存锁定。这两个动作不需要显式的事件触发只要状态迁移发生就会执行。实际建模时把那些“只要进入这个状态就必须做的事”放到入口动作里能大幅简化迁移线上的动作标注。2.2 迁移状态之间的有向边迁移用带箭头的实线表示从源状态指向目标状态。一条完整的迁移可以包含五个部分源状态、触发事件、守卫条件、动作、目标状态。写成标准格式就是事件 [守卫条件] / 动作。守卫条件是一个布尔表达式只有为真时迁移才会发生。比如“支付成功 [金额0] / 更新订单状态”这条迁移如果金额为0即使收到支付成功事件也不会触发迁移。守卫条件和事件的区别在于事件是外部触发的信号守卫条件是内部判断的逻辑。事件回答“什么时候可以考虑迁移”守卫条件回答“这次迁移到底允不允许”。自迁移是一种特殊形式源状态和目标状态是同一个。比如“待支付”状态下收到“查询支付结果”事件如果支付仍未完成就自迁移回“待支付”同时执行一个“更新查询时间”的动作。自迁移不会触发入口动作和出口动作只会执行迁移线上的动作这个细节在实现时要特别注意。2.3 事件驱动状态变化的扳机事件是状态迁移的触发器分为几种类型。信号事件是异步的、显式发送的消息比如用户点击按钮、外部系统回调。调用事件是同步的方法调用比如订单服务调用库存服务的扣减接口。时间事件是到达某个时间点或经过某段时间后自动触发的事件用after(时间表达式)表示比如after(30分钟)表示30分钟后触发。变化事件是某个条件变为真时触发用when(条件)表示比如when(库存10)。时间事件在订单超时关闭、会话超时失效、定时任务触发这些场景里非常实用。但要注意时间事件的计时起点是进入源状态的时刻不是系统启动的时刻。如果订单在“待支付”状态停留了30分钟after(30分钟)就会触发如果中途迁移到其他状态又回来计时会重新开始。2.4 动作迁移过程中执行的操作动作写在迁移线上用斜杠分隔。动作可以是发送消息、调用方法、设置属性值、触发另一个状态机等。动作的执行时机是在迁移过程中源状态的出口动作之后、目标状态的入口动作之前。这个顺序很重要因为如果动作依赖源状态的某些数据必须在出口动作之前读取如果动作要设置目标状态需要的数据必须在入口动作之前完成。动作和活动的区别也经常被搞混。活动是状态内部持续执行的行为用do/活动名表示比如“处理中”状态下do/轮询支付结果。活动在进入状态时开始在离开状态时被中断。动作是瞬时的活动是持续的。一个状态可以有多个活动但通常只写一个主要的。3. 从零画一张能落地的订单状态图3.1 先定边界哪些状态值得画拿到一个订单系统不要上来就画。先问自己三个问题这个对象的生命周期起点和终点分别是什么中间有哪些稳定且可命名的阶段每个阶段对外表现出的行为差异是什么以订单为例起点是“创建”终点是“已完成”或“已取消”。中间阶段我通常会先列出候选状态待支付、支付中、已支付、待发货、已发货、待收货、已收货、已完成、已取消、退款中、已退款。然后做减法支付中这个状态如果支付网关的回调是同步的可能不需要单独建模待收货和已收货如果业务上不区分可以合并。状态不是越多越好每个状态都应该有独立的业务含义和不同的可响应事件集合。如果两个状态能响应的事件完全一样只是名字不同那大概率可以合并。3.2 再定事件每个状态下能发生什么状态定完后逐个状态列出它能响应的事件。待支付状态下能响应的事件有用户支付成功、用户取消订单、超时未支付、系统风控拦截。已支付状态下能响应的事件有仓库发货、用户申请退款、系统自动审核通过。已发货状态下能响应的事件有用户确认收货、物流签收回调、超时自动确认。这一步的关键是穷举。我习惯用表格来整理行是状态列是事件交叉点填写迁移目标和动作。这样能直观地看出哪些状态缺少事件死状态、哪些事件在多个状态下都能触发需要守卫条件区分、哪些迁移路径是业务上不允许的需要显式禁止。当前状态事件守卫条件目标状态动作待支付支付成功金额匹配已支付记录支付时间待支付用户取消无已取消释放库存待支付超时超过30分钟已取消释放库存、通知用户已支付申请退款未发货退款中冻结订单已支付仓库发货库存充足已发货生成物流单已发货确认收货无已完成结算货款3.3 补全动作迁移时到底做了什么动作的粒度需要把握好。太粗了没有指导意义太细了变成伪代码。我的经验是动作描述的是“做什么”不是“怎么做”。写“释放库存”就够了不需要写“调用库存服务的release接口传入订单号和商品列表”。后者是实现细节应该放在详细设计文档里不是状态图的职责。但有一个动作必须写清楚状态变更本身的持久化。很多线上事故的根因就是状态迁移了但数据库没更新或者数据库更新了但缓存没失效。在状态图上我通常会在每个迁移的动作里显式标注“持久化状态”和“失效缓存”提醒实现者不要漏掉。3.4 验证用状态图推导测试用例状态图画完后怎么验证它是对的一个实用的方法是状态覆盖和迁移覆盖。状态覆盖要求每个状态至少被进入一次迁移覆盖要求每条迁移至少被执行一次。对于订单状态图这意味着测试用例要覆盖正常支付流程、支付后取消、支付后超时、发货后退款、收货后完成、以及各种异常路径。更严格的是路径覆盖要求覆盖所有可能的迁移序列。但路径数量会随状态数指数增长实际项目中通常只覆盖一到两个典型路径加上所有异常路径。状态图在这里的价值是它让测试用例的设计有据可依而不是靠测试人员的直觉。每条迁移对应至少一个测试用例每个守卫条件对应至少两个测试用例条件为真和为假。4. 状态图在代码里的三种落地姿势4.1 枚举加if-else小规模场景够用但不推荐最简单的落地方式就是定义状态枚举然后在业务方法里写if-else判断当前状态决定能不能执行某个操作。比如public void pay(Order order) { if (order.getStatus() OrderStatus.PENDING_PAYMENT) { order.setStatus(OrderStatus.PAID); order.setPayTime(new Date()); } else { throw new IllegalStateException(当前状态不允许支付); } }这种方式在状态少于5个、迁移逻辑简单的情况下能用但一旦状态超过7个、迁移路径超过15条代码就会变成一团乱麻。更致命的是状态迁移规则散落在各个业务方法里没有单一事实来源。产品改一条规则开发要翻遍所有方法去找哪里需要改漏改一处就是线上事故。4.2 状态机引擎把迁移规则配置化中等规模以上的系统我强烈建议引入状态机引擎。核心思路是把状态、事件、迁移、守卫条件、动作都配置化业务代码只负责触发事件引擎负责判断能不能迁移、迁移到哪、执行什么动作。以Spring StateMachine为例配置大致长这样Configuration EnableStateMachine public class OrderStateMachineConfig extends StateMachineConfigurerAdapterOrderStatus, OrderEvent { Override public void configure(StateMachineTransitionConfigurerOrderStatus, OrderEvent transitions) throws Exception { transitions .withExternal() .source(OrderStatus.PENDING_PAYMENT) .target(OrderStatus.PAID) .event(OrderEvent.PAY_SUCCESS) .guard(paymentGuard()) .action(paymentAction()) .and() .withExternal() .source(OrderStatus.PENDING_PAYMENT) .target(OrderStatus.CANCELLED) .event(OrderEvent.USER_CANCEL) .action(cancelAction()); } }这种方式的优势很明显迁移规则集中在一处改规则只改配置守卫条件和动作可以复用引擎自带状态机上下文能记录当前状态和历史状态。缺点是学习曲线陡峭配置复杂调试时如果出问题需要理解引擎的内部机制。4.3 领域驱动设计中的状态模式把状态行为封装到状态对象里另一种思路是用状态模式每个状态是一个类状态类负责定义在这个状态下能响应什么事件、迁移到哪个状态。订单对象持有一个当前状态对象收到事件时委托给当前状态对象处理。public interface OrderState { OrderStatus getStatus(); OrderState pay(OrderContext context); OrderState cancel(OrderContext context); OrderState ship(OrderContext context); } public class PendingPaymentState implements OrderState { Override public OrderState pay(OrderContext context) { context.setPayTime(new Date()); return new PaidState(); } Override public OrderState cancel(OrderContext context) { context.releaseInventory(); return new CancelledState(); } Override public OrderState ship(OrderContext context) { throw new IllegalStateException(待支付状态不能发货); } }这种方式和领域驱动设计的契合度最高状态迁移逻辑内聚在状态类里新增状态只需要新增一个类符合开闭原则。缺点是类数量会膨胀每个状态一个类状态多了之后包结构会变得很重。三种方式怎么选我的经验是状态少于5个用枚举加if-else5到15个用状态机引擎15个以上或者状态行为差异很大用状态模式。但不管用哪种方式状态图都是设计阶段必须产出的文档它和代码实现方式是正交的。5. 那些年我在状态建模上踩过的坑5.1 状态爆炸把动作当状态早期做审批流的时候我把“发送邮件通知”“生成PDF”“调用外部接口”都画成了状态结果一张图上有三十多个圆角矩形评审的时候没人看得懂。后来才明白状态是对象所处的条件动作是对象执行的操作。发送邮件是动作不是状态邮件已发送才是状态。把动作从状态里剥离出去之后状态数量从三十多个降到了八个图一下子就清晰了。判断一个节点该不该画成状态有个简单的测试这个节点能响应事件吗如果能响应至少一个事件并发生迁移它就是状态如果只是执行一个操作然后自动进入下一个节点那它是动作或者活动应该合并到迁移线上或者状态内部。5.2 守卫条件写成了业务逻辑守卫条件应该是一个轻量的布尔判断比如“金额大于0”“库存充足”“用户等级为VIP”。但我见过有人在守卫条件里写数据库查询、调用远程接口、甚至发消息。这会导致两个问题一是状态机执行变慢因为每次迁移都要等远程调用返回二是守卫条件有副作用判断本身改变了系统状态这在语义上就错了。守卫条件的正确用法是只做内存中的简单判断复杂判断前置到事件触发之前。比如“库存充足”这个守卫条件应该在触发支付事件之前就查好库存把结果作为事件参数传进来而不是在守卫条件里现查。5.3 忽略了并发状态迁移订单系统最常见的并发问题就是用户同时点了“支付”和“取消”两个事件几乎同时到达。如果状态机没有并发控制可能出现支付成功后又执行了取消动作订单状态变成已取消但钱已经扣了。解决方式有两种。乐观锁在状态迁移时检查版本号如果版本号变了就拒绝迁移。悲观锁在进入状态机之前先加锁保证同一时刻只有一个事件在处理。我通常用乐观锁因为状态迁移本身应该是低频操作冲突概率不高乐观锁的性能更好。但要注意乐观锁失败后要返回明确的错误提示让用户知道“订单状态已变化请刷新后重试”。5.4 状态图更新不及时这是最隐蔽的坑。代码改了状态迁移逻辑但状态图没更新导致文档和实现不一致。下次新人接手时照着状态图理解业务结果发现代码行为对不上排查半天才发现是图过时了。我的做法是把状态图纳入代码评审的检查项。任何涉及状态迁移的代码变更必须同时更新状态图。如果团队用Git管理文档可以把状态图的源文件比如PlantUML文本和代码放在同一个仓库代码评审时一起看。PlantUML的好处是文本格式diff起来很清楚不像图片那样只能整体替换。6. 让状态图真正发挥价值的几个实践习惯6.1 从异常路径开始画而不是正常路径大多数人画状态图习惯从正常流程开始创建→支付→发货→收货→完成。但正常路径往往很简单真正复杂的是异常路径支付超时怎么办发货后用户退款怎么办收货后发现有质量问题怎么办这些异常路径才是状态图的价值所在。我的习惯是先画异常路径再补正常路径。因为异常路径涉及的状态迁移更多、守卫条件更复杂、动作更容易遗漏。先把异常路径理清楚正常路径自然就出来了。而且异常路径往往是线上事故的高发区提前建模能避免很多问题。6.2 给每个状态定义明确的“可响应事件集合”状态图的一个核心价值是明确边界在某个状态下哪些事件是允许的哪些是禁止的。我习惯在状态图的每个状态旁边标注“允许的事件”和“禁止的事件”。禁止的事件不是不画而是显式标注出来提醒实现者要抛出明确的异常而不是静默忽略。比如“已取消”状态下收到“支付成功”事件应该抛出“订单已取消无法支付”的异常而不是什么都不做。静默忽略会让调用方以为支付成功了实际上订单已经取消了这种bug在线上非常难排查。6.3 用子状态机管理复杂度当一个状态内部的逻辑也很复杂时不要试图在一张图里画完用复合状态拆成子状态机。比如“订单处理中”这个状态内部可以拆成“库存锁定”“支付确认”“物流分配”三个子状态。每个子状态有自己的迁移逻辑对外只暴露“处理完成”和“处理失败”两个事件。子状态机的好处是分层抽象。高层状态图只关心“订单处理中”这个状态的整体行为不关心内部细节低层子状态机关心具体步骤。这样不同角色的读者可以关注不同层级产品经理看高层开发看低层测试两层都看。6.4 状态命名用“过去分词”或“形容词”状态命名的规范看似小事但影响很大。“支付”是动词不适合做状态名“已支付”是过去分词表示一个已经完成的条件适合做状态名。“待支付”是形容词性的表示当前的条件也适合。统一用“已XX”或“待XX”的格式能让状态图读起来更自然也更容易和代码里的枚举命名对应上。我见过有人用“支付中”做状态名但“支付中”到底是一个稳定状态还是一个瞬时动作如果是稳定状态它和“待支付”“已支付”的区别是什么这种模糊命名会导致实现时产生歧义。我的建议是如果一个状态不能稳定存在超过一个业务操作的时间它大概率不应该是一个独立状态。6.5 状态图不是画完就完了要持续维护状态图是活文档不是一次性交付物。每次业务规则变更、每次新增状态、每次修改迁移条件都应该同步更新状态图。我通常会在状态图的源文件里加一个变更记录表记录每次修改的日期、修改人、修改内容。这样追溯起来很方便也能看出哪些状态是后来加的、为什么加。如果团队用Confluence或者类似的文档工具可以把状态图嵌入到需求文档里需求变更时强制更新。如果团队用代码仓库管理文档可以把状态图放在和代码同一个目录下代码评审时一起看。关键是让更新状态图的成本足够低低到大家愿意做这件事。PlantUML、Mermaid这些文本化工具在这方面有天然优势改几个字符就能更新不需要打开绘图软件拖拽。状态图这个工具入门容易精通难。画出一张能看的图不难画出一张能指导实现、能推导测试、能对齐认知的图需要大量的实践和踩坑。我到现在也不敢说每张状态图都画得完美但至少每次画之前都会问自己这个状态真的需要独立存在吗这条迁移的守卫条件是不是太重了异常路径覆盖全了吗这三个问题问下来图的质素通常不会太差。
1. 状态图到底在解决什么问题很多人第一次接触UML状态图是在需求评审或者系统设计文档里看到一堆圆角矩形和箭头觉得这玩意儿就是画着好看、评审时凑页数用的。我刚开始做后端开发那几年也是这么想的直到有一次做一个订单履约系统状态流转逻辑写了两千多行if-else上线后每隔几天就出一个状态错乱的生产事故排查起来像大海捞针才真正意识到状态图的价值。状态图State Diagram本质上是一种描述对象生命周期行为的建模工具。它关注的不是“谁调用谁”也不是“数据怎么流”而是一个对象在它的生命期内会经历哪些状态、在什么条件下从一个状态迁移到另一个状态、迁移时触发什么动作。这个“对象”可以是一个订单、一个支付单、一个工单、一个设备连接、一个用户会话甚至是一个前端页面的交互流程。它解决的核心问题就一个把散落在代码各处的状态判断逻辑提前用一种所有人都能看懂的方式固化下来。产品经理能看懂测试能看懂后端能看懂前端也能看懂。大家在同一个语义平面上讨论“订单从待支付变成已支付到底需不需要经过风控审核这个中间态”而不是等到代码写完才发现产品想的和开发做的根本不是一回事。状态图和流程图的区别经常被混淆。流程图描述的是“做事的步骤”强调的是动作的先后顺序状态图描述的是“对象的状态”强调的是在某个状态下能响应什么事件、响应后跳到哪个状态。举个例子流程图会说“先校验库存再扣减库存再生成订单”状态图会说“订单处于待确认状态时收到库存充足事件则迁移到已确认状态收到库存不足事件则迁移到已取消状态”。前者是过程视角后者是对象视角。两者互补不能互相替代。适合学习状态图的人其实比想象中多。后端工程师用它来设计订单、支付、工单等有明确生命周期的领域对象前端工程师用它来管理复杂页面的交互状态避免出现“加载中又弹了错误提示”这种状态冲突测试工程师用它来推导状态覆盖的测试用例保证每个迁移路径都被验证过产品经理用它来和开发对齐业务规则减少口头沟通的歧义。只要你面对的对象有“状态”这个概念状态图就值得花时间掌握。2. 状态图的四根支柱状态、迁移、事件、动作2.1 状态不只是“当前处于什么阶段”状态在状态图里用圆角矩形表示看起来简单但实际建模时最容易出问题。很多人会把“动作”当成“状态”比如把“发送短信”画成一个状态这就错了——发送短信是一个动作不是对象所处的稳定条件。状态的定义是对象在某个时间段内满足的某种条件或情形。它应该是稳定的、可命名的、有明确语义的。状态分为几种类型。简单状态就是普通的圆角矩形比如“待支付”“已支付”“已发货”。复合状态内部还嵌套了子状态机比如“订单处理中”这个状态内部又分为“库存锁定中”“支付确认中”“物流分配中”三个子状态。复合状态的价值在于分层表达避免一张图铺得太大看不清。历史状态用圆圈里加H表示作用是记住复合状态上次退出时停留在哪个子状态下次进入时直接恢复而不是从头开始。这个在订单超时后重新激活的场景里特别有用。还有一个容易被忽略的概念是入口动作和出口动作。入口动作是进入某个状态时自动执行的动作出口动作是离开某个状态时自动执行的动作。比如进入“已支付”状态时自动发送支付成功通知离开“待支付”状态时自动释放库存锁定。这两个动作不需要显式的事件触发只要状态迁移发生就会执行。实际建模时把那些“只要进入这个状态就必须做的事”放到入口动作里能大幅简化迁移线上的动作标注。2.2 迁移状态之间的有向边迁移用带箭头的实线表示从源状态指向目标状态。一条完整的迁移可以包含五个部分源状态、触发事件、守卫条件、动作、目标状态。写成标准格式就是事件 [守卫条件] / 动作。守卫条件是一个布尔表达式只有为真时迁移才会发生。比如“支付成功 [金额0] / 更新订单状态”这条迁移如果金额为0即使收到支付成功事件也不会触发迁移。守卫条件和事件的区别在于事件是外部触发的信号守卫条件是内部判断的逻辑。事件回答“什么时候可以考虑迁移”守卫条件回答“这次迁移到底允不允许”。自迁移是一种特殊形式源状态和目标状态是同一个。比如“待支付”状态下收到“查询支付结果”事件如果支付仍未完成就自迁移回“待支付”同时执行一个“更新查询时间”的动作。自迁移不会触发入口动作和出口动作只会执行迁移线上的动作这个细节在实现时要特别注意。2.3 事件驱动状态变化的扳机事件是状态迁移的触发器分为几种类型。信号事件是异步的、显式发送的消息比如用户点击按钮、外部系统回调。调用事件是同步的方法调用比如订单服务调用库存服务的扣减接口。时间事件是到达某个时间点或经过某段时间后自动触发的事件用after(时间表达式)表示比如after(30分钟)表示30分钟后触发。变化事件是某个条件变为真时触发用when(条件)表示比如when(库存10)。时间事件在订单超时关闭、会话超时失效、定时任务触发这些场景里非常实用。但要注意时间事件的计时起点是进入源状态的时刻不是系统启动的时刻。如果订单在“待支付”状态停留了30分钟after(30分钟)就会触发如果中途迁移到其他状态又回来计时会重新开始。2.4 动作迁移过程中执行的操作动作写在迁移线上用斜杠分隔。动作可以是发送消息、调用方法、设置属性值、触发另一个状态机等。动作的执行时机是在迁移过程中源状态的出口动作之后、目标状态的入口动作之前。这个顺序很重要因为如果动作依赖源状态的某些数据必须在出口动作之前读取如果动作要设置目标状态需要的数据必须在入口动作之前完成。动作和活动的区别也经常被搞混。活动是状态内部持续执行的行为用do/活动名表示比如“处理中”状态下do/轮询支付结果。活动在进入状态时开始在离开状态时被中断。动作是瞬时的活动是持续的。一个状态可以有多个活动但通常只写一个主要的。3. 从零画一张能落地的订单状态图3.1 先定边界哪些状态值得画拿到一个订单系统不要上来就画。先问自己三个问题这个对象的生命周期起点和终点分别是什么中间有哪些稳定且可命名的阶段每个阶段对外表现出的行为差异是什么以订单为例起点是“创建”终点是“已完成”或“已取消”。中间阶段我通常会先列出候选状态待支付、支付中、已支付、待发货、已发货、待收货、已收货、已完成、已取消、退款中、已退款。然后做减法支付中这个状态如果支付网关的回调是同步的可能不需要单独建模待收货和已收货如果业务上不区分可以合并。状态不是越多越好每个状态都应该有独立的业务含义和不同的可响应事件集合。如果两个状态能响应的事件完全一样只是名字不同那大概率可以合并。3.2 再定事件每个状态下能发生什么状态定完后逐个状态列出它能响应的事件。待支付状态下能响应的事件有用户支付成功、用户取消订单、超时未支付、系统风控拦截。已支付状态下能响应的事件有仓库发货、用户申请退款、系统自动审核通过。已发货状态下能响应的事件有用户确认收货、物流签收回调、超时自动确认。这一步的关键是穷举。我习惯用表格来整理行是状态列是事件交叉点填写迁移目标和动作。这样能直观地看出哪些状态缺少事件死状态、哪些事件在多个状态下都能触发需要守卫条件区分、哪些迁移路径是业务上不允许的需要显式禁止。当前状态事件守卫条件目标状态动作待支付支付成功金额匹配已支付记录支付时间待支付用户取消无已取消释放库存待支付超时超过30分钟已取消释放库存、通知用户已支付申请退款未发货退款中冻结订单已支付仓库发货库存充足已发货生成物流单已发货确认收货无已完成结算货款3.3 补全动作迁移时到底做了什么动作的粒度需要把握好。太粗了没有指导意义太细了变成伪代码。我的经验是动作描述的是“做什么”不是“怎么做”。写“释放库存”就够了不需要写“调用库存服务的release接口传入订单号和商品列表”。后者是实现细节应该放在详细设计文档里不是状态图的职责。但有一个动作必须写清楚状态变更本身的持久化。很多线上事故的根因就是状态迁移了但数据库没更新或者数据库更新了但缓存没失效。在状态图上我通常会在每个迁移的动作里显式标注“持久化状态”和“失效缓存”提醒实现者不要漏掉。3.4 验证用状态图推导测试用例状态图画完后怎么验证它是对的一个实用的方法是状态覆盖和迁移覆盖。状态覆盖要求每个状态至少被进入一次迁移覆盖要求每条迁移至少被执行一次。对于订单状态图这意味着测试用例要覆盖正常支付流程、支付后取消、支付后超时、发货后退款、收货后完成、以及各种异常路径。更严格的是路径覆盖要求覆盖所有可能的迁移序列。但路径数量会随状态数指数增长实际项目中通常只覆盖一到两个典型路径加上所有异常路径。状态图在这里的价值是它让测试用例的设计有据可依而不是靠测试人员的直觉。每条迁移对应至少一个测试用例每个守卫条件对应至少两个测试用例条件为真和为假。4. 状态图在代码里的三种落地姿势4.1 枚举加if-else小规模场景够用但不推荐最简单的落地方式就是定义状态枚举然后在业务方法里写if-else判断当前状态决定能不能执行某个操作。比如public void pay(Order order) { if (order.getStatus() OrderStatus.PENDING_PAYMENT) { order.setStatus(OrderStatus.PAID); order.setPayTime(new Date()); } else { throw new IllegalStateException(当前状态不允许支付); } }这种方式在状态少于5个、迁移逻辑简单的情况下能用但一旦状态超过7个、迁移路径超过15条代码就会变成一团乱麻。更致命的是状态迁移规则散落在各个业务方法里没有单一事实来源。产品改一条规则开发要翻遍所有方法去找哪里需要改漏改一处就是线上事故。4.2 状态机引擎把迁移规则配置化中等规模以上的系统我强烈建议引入状态机引擎。核心思路是把状态、事件、迁移、守卫条件、动作都配置化业务代码只负责触发事件引擎负责判断能不能迁移、迁移到哪、执行什么动作。以Spring StateMachine为例配置大致长这样Configuration EnableStateMachine public class OrderStateMachineConfig extends StateMachineConfigurerAdapterOrderStatus, OrderEvent { Override public void configure(StateMachineTransitionConfigurerOrderStatus, OrderEvent transitions) throws Exception { transitions .withExternal() .source(OrderStatus.PENDING_PAYMENT) .target(OrderStatus.PAID) .event(OrderEvent.PAY_SUCCESS) .guard(paymentGuard()) .action(paymentAction()) .and() .withExternal() .source(OrderStatus.PENDING_PAYMENT) .target(OrderStatus.CANCELLED) .event(OrderEvent.USER_CANCEL) .action(cancelAction()); } }这种方式的优势很明显迁移规则集中在一处改规则只改配置守卫条件和动作可以复用引擎自带状态机上下文能记录当前状态和历史状态。缺点是学习曲线陡峭配置复杂调试时如果出问题需要理解引擎的内部机制。4.3 领域驱动设计中的状态模式把状态行为封装到状态对象里另一种思路是用状态模式每个状态是一个类状态类负责定义在这个状态下能响应什么事件、迁移到哪个状态。订单对象持有一个当前状态对象收到事件时委托给当前状态对象处理。public interface OrderState { OrderStatus getStatus(); OrderState pay(OrderContext context); OrderState cancel(OrderContext context); OrderState ship(OrderContext context); } public class PendingPaymentState implements OrderState { Override public OrderState pay(OrderContext context) { context.setPayTime(new Date()); return new PaidState(); } Override public OrderState cancel(OrderContext context) { context.releaseInventory(); return new CancelledState(); } Override public OrderState ship(OrderContext context) { throw new IllegalStateException(待支付状态不能发货); } }这种方式和领域驱动设计的契合度最高状态迁移逻辑内聚在状态类里新增状态只需要新增一个类符合开闭原则。缺点是类数量会膨胀每个状态一个类状态多了之后包结构会变得很重。三种方式怎么选我的经验是状态少于5个用枚举加if-else5到15个用状态机引擎15个以上或者状态行为差异很大用状态模式。但不管用哪种方式状态图都是设计阶段必须产出的文档它和代码实现方式是正交的。5. 那些年我在状态建模上踩过的坑5.1 状态爆炸把动作当状态早期做审批流的时候我把“发送邮件通知”“生成PDF”“调用外部接口”都画成了状态结果一张图上有三十多个圆角矩形评审的时候没人看得懂。后来才明白状态是对象所处的条件动作是对象执行的操作。发送邮件是动作不是状态邮件已发送才是状态。把动作从状态里剥离出去之后状态数量从三十多个降到了八个图一下子就清晰了。判断一个节点该不该画成状态有个简单的测试这个节点能响应事件吗如果能响应至少一个事件并发生迁移它就是状态如果只是执行一个操作然后自动进入下一个节点那它是动作或者活动应该合并到迁移线上或者状态内部。5.2 守卫条件写成了业务逻辑守卫条件应该是一个轻量的布尔判断比如“金额大于0”“库存充足”“用户等级为VIP”。但我见过有人在守卫条件里写数据库查询、调用远程接口、甚至发消息。这会导致两个问题一是状态机执行变慢因为每次迁移都要等远程调用返回二是守卫条件有副作用判断本身改变了系统状态这在语义上就错了。守卫条件的正确用法是只做内存中的简单判断复杂判断前置到事件触发之前。比如“库存充足”这个守卫条件应该在触发支付事件之前就查好库存把结果作为事件参数传进来而不是在守卫条件里现查。5.3 忽略了并发状态迁移订单系统最常见的并发问题就是用户同时点了“支付”和“取消”两个事件几乎同时到达。如果状态机没有并发控制可能出现支付成功后又执行了取消动作订单状态变成已取消但钱已经扣了。解决方式有两种。乐观锁在状态迁移时检查版本号如果版本号变了就拒绝迁移。悲观锁在进入状态机之前先加锁保证同一时刻只有一个事件在处理。我通常用乐观锁因为状态迁移本身应该是低频操作冲突概率不高乐观锁的性能更好。但要注意乐观锁失败后要返回明确的错误提示让用户知道“订单状态已变化请刷新后重试”。5.4 状态图更新不及时这是最隐蔽的坑。代码改了状态迁移逻辑但状态图没更新导致文档和实现不一致。下次新人接手时照着状态图理解业务结果发现代码行为对不上排查半天才发现是图过时了。我的做法是把状态图纳入代码评审的检查项。任何涉及状态迁移的代码变更必须同时更新状态图。如果团队用Git管理文档可以把状态图的源文件比如PlantUML文本和代码放在同一个仓库代码评审时一起看。PlantUML的好处是文本格式diff起来很清楚不像图片那样只能整体替换。6. 让状态图真正发挥价值的几个实践习惯6.1 从异常路径开始画而不是正常路径大多数人画状态图习惯从正常流程开始创建→支付→发货→收货→完成。但正常路径往往很简单真正复杂的是异常路径支付超时怎么办发货后用户退款怎么办收货后发现有质量问题怎么办这些异常路径才是状态图的价值所在。我的习惯是先画异常路径再补正常路径。因为异常路径涉及的状态迁移更多、守卫条件更复杂、动作更容易遗漏。先把异常路径理清楚正常路径自然就出来了。而且异常路径往往是线上事故的高发区提前建模能避免很多问题。6.2 给每个状态定义明确的“可响应事件集合”状态图的一个核心价值是明确边界在某个状态下哪些事件是允许的哪些是禁止的。我习惯在状态图的每个状态旁边标注“允许的事件”和“禁止的事件”。禁止的事件不是不画而是显式标注出来提醒实现者要抛出明确的异常而不是静默忽略。比如“已取消”状态下收到“支付成功”事件应该抛出“订单已取消无法支付”的异常而不是什么都不做。静默忽略会让调用方以为支付成功了实际上订单已经取消了这种bug在线上非常难排查。6.3 用子状态机管理复杂度当一个状态内部的逻辑也很复杂时不要试图在一张图里画完用复合状态拆成子状态机。比如“订单处理中”这个状态内部可以拆成“库存锁定”“支付确认”“物流分配”三个子状态。每个子状态有自己的迁移逻辑对外只暴露“处理完成”和“处理失败”两个事件。子状态机的好处是分层抽象。高层状态图只关心“订单处理中”这个状态的整体行为不关心内部细节低层子状态机关心具体步骤。这样不同角色的读者可以关注不同层级产品经理看高层开发看低层测试两层都看。6.4 状态命名用“过去分词”或“形容词”状态命名的规范看似小事但影响很大。“支付”是动词不适合做状态名“已支付”是过去分词表示一个已经完成的条件适合做状态名。“待支付”是形容词性的表示当前的条件也适合。统一用“已XX”或“待XX”的格式能让状态图读起来更自然也更容易和代码里的枚举命名对应上。我见过有人用“支付中”做状态名但“支付中”到底是一个稳定状态还是一个瞬时动作如果是稳定状态它和“待支付”“已支付”的区别是什么这种模糊命名会导致实现时产生歧义。我的建议是如果一个状态不能稳定存在超过一个业务操作的时间它大概率不应该是一个独立状态。6.5 状态图不是画完就完了要持续维护状态图是活文档不是一次性交付物。每次业务规则变更、每次新增状态、每次修改迁移条件都应该同步更新状态图。我通常会在状态图的源文件里加一个变更记录表记录每次修改的日期、修改人、修改内容。这样追溯起来很方便也能看出哪些状态是后来加的、为什么加。如果团队用Confluence或者类似的文档工具可以把状态图嵌入到需求文档里需求变更时强制更新。如果团队用代码仓库管理文档可以把状态图放在和代码同一个目录下代码评审时一起看。关键是让更新状态图的成本足够低低到大家愿意做这件事。PlantUML、Mermaid这些文本化工具在这方面有天然优势改几个字符就能更新不需要打开绘图软件拖拽。状态图这个工具入门容易精通难。画出一张能看的图不难画出一张能指导实现、能推导测试、能对齐认知的图需要大量的实践和踩坑。我到现在也不敢说每张状态图都画得完美但至少每次画之前都会问自己这个状态真的需要独立存在吗这条迁移的守卫条件是不是太重了异常路径覆盖全了吗这三个问题问下来图的质素通常不会太差。
