1. 状态机图到底解决什么问题1.1 从一个真实场景说起做过订单系统的人大概都遇到过这种局面产品经理拿着一份需求文档过来上面写着“订单状态包括待支付、已支付、已发货、已完成、已取消、退款中、已退款”然后问你“这些状态之间怎么跳转”。如果你只是用文字描述写出来的东西大概率是这样的“待支付可以取消也可以支付支付后可以发货发货后可以确认收货确认收货后可以申请退款……”这种描述读起来没问题但一旦状态数量超过七八个跳转关系超过十几条文字就彻底失控了。更麻烦的是开发、测试、产品三方对同一段文字的理解可能完全不同测试写用例时漏掉一条跳转路径上线后就是一个线上缺陷。状态机图就是用来解决这个问题的。它把“对象在生命周期中经历哪些状态、什么事件触发状态切换、切换时执行什么动作”这三件事用一张图说清楚。UML 状态机图State Machine Diagram也常被叫做状态图 State Diagram是 UML 中专门用于描述单个对象动态行为的图种和活动图、时序图、用例图并列但侧重点完全不同。1.2 状态机图在 UML 体系中的位置UML 的动态结构图包括活动图、时序图、协作图、状态机图这几种。很多人分不清状态机图和活动图这里给一个最简单的区分方法活动图描述的是“一件事从头到尾的流程”状态机图描述的是“一个对象在不同阶段的状态变化”。活动图的主角是“流程”状态机图的主角是“对象”。举个例子一个电商订单从创建到完成如果用活动图画你会看到“用户下单→系统校验库存→生成订单→等待支付→……”这样的流程节点如果用状态机图画你会看到“待支付”这个状态收到“支付成功”事件后迁移到“已支付”状态收到“取消”事件后迁移到“已取消”状态。前者关注“做了什么”后者关注“处于什么状态”。状态机图特别适合以下几类场景订单、工单、审批流、设备控制、协议交互、游戏角色状态、PLC 控制逻辑等。凡是“一个东西有明确的生命周期且在不同阶段对同一事件有不同响应”的场景状态机图都是首选建模工具。1.3 谁需要掌握状态机图如果你在做后端业务开发尤其是订单、支付、审批、风控这类系统状态机图几乎是必备技能。如果你在做嵌入式或工业控制PLCopen 状态机图那套东西和 UML 状态机图在思想上是一脉相承的。如果你在准备软考中级UML 建模是必考内容状态机图经常出现在下午题里。如果你在用 PowerDesigner 做数据库设计状态机图也能帮你把业务状态和数据库状态字段对应起来。这篇文章我会从状态机图的核心要素讲起然后给出完整的实操步骤包括用工具画图的技巧、状态设计的常见模式、以及我在实际项目中踩过的坑。目标很明确看完之后你能独立画出一张能直接给开发和测试用的状态机图而不是一张只有自己看得懂的草图。2. 状态机图的核心要素拆解2.1 状态、迁移、事件、动作四件套状态机图的核心就四个概念但每个概念都有容易踩坑的细节。状态State是对象在生命周期中的一个条件或状况在这个状况下对象满足某些条件、执行某些活动或等待某些事件。状态的画法是一个圆角矩形里面写状态名。状态名一般用“形容词名词”或“动词过去式”的形式比如“待支付”“已发货”“审核中”。这里有个经验状态名一定要用完成态或进行态不要用动词原形。我见过有人把状态写成“支付”这就很模糊到底是“等待支付”还是“正在支付”还是“支付完成”状态名必须让读者一眼看出对象当前处于什么阶段。迁移Transition是两个状态之间的有向连线表示对象在特定事件触发下从一个状态切换到另一个状态。迁移的画法是一条带箭头的实线箭头上可以标注“事件[守卫条件]/动作”。这里的关键是迁移是由事件驱动的没有事件就不会发生迁移。很多新手画状态机图时喜欢画一条从 A 到 B 的线但不标事件这种图在评审时一定会被问“什么情况下会从 A 到 B”。事件Event是触发状态迁移的事情。事件可以是信号事件收到某个消息、调用事件某个操作被调用、时间事件到达某个时间点、变化事件某个条件变为真。事件写在迁移箭头上格式是“事件名(参数)”。比如“支付成功(orderId)”“超时(30min)”。动作Action是状态迁移时执行的操作可以是发送消息、调用操作、设置属性等。动作写在事件后面用斜杠分隔比如“支付成功/更新订单状态”。动作必须是原子性的、不可中断的执行时间极短。如果某个操作需要较长时间应该建模为状态内的活动do 活动而不是迁移上的动作。2.2 状态内部的三个分区entry、do、exit一个状态内部可以定义三种活动这是状态机图区别于普通流程图的关键特性。entry 活动进入该状态时立即执行的动作只执行一次。比如进入“已支付”状态时entry 活动可以是“发送支付成功通知”。do 活动处于该状态期间持续执行的活动可以被中断。比如“退款中”状态的 do 活动可以是“等待退款渠道返回结果”。exit 活动离开该状态时执行的动作只执行一次。比如离开“已支付”状态时exit 活动可以是“记录支付完成时间”。这三个活动的执行顺序是先执行源状态的 exit再执行迁移上的动作最后执行目标状态的 entry。do 活动在状态持续期间执行如果状态在 do 活动完成前就迁移走了do 活动会被中断。我见过很多团队画状态机图时只画状态和迁移完全不写 entry/do/exit结果开发实现时全靠猜。比如“已支付”状态到底要不要发通知什么时候发如果不在图上写清楚不同开发可能写出完全不同的代码。所以我的建议是只要状态内有明确的进入动作、持续活动或退出动作就一定要在图上标出来。2.3 复合状态与区域处理复杂状态的利器当状态数量变多时平铺的状态机图会变得非常庞大。这时候就需要用到复合状态Composite State和区域Region。复合状态是一个包含子状态的状态。比如“订单处理中”这个状态可以包含“待支付”“已支付”“已发货”三个子状态。复合状态的好处是可以把相关的状态聚合在一起对外表现为一个状态对内可以有自己的子状态机。区域是复合状态内部可以并行执行的多个子状态机。比如一个订单同时有“支付状态”和“物流状态”两条线支付状态有“待支付/已支付/已退款”物流状态有“未发货/已发货/已签收”。这两条线是并行独立的用区域来建模就非常合适。区域之间用虚线分隔每个区域有自己的初始状态和终止状态。这里有个容易混淆的点复合状态和区域的区别。复合状态是“包含”区域是“并行”。一个复合状态内部可以有多个区域每个区域内部又可以有自己的子状态。实际项目中我一般建议状态数量超过 10 个时就开始考虑用复合状态分组否则图会变得难以阅读。2.4 伪状态初始、终止、选择、合并、历史伪状态是状态机图中不表示实际状态、但控制迁移逻辑的特殊节点。初始伪状态一个实心黑圆点表示状态机的起点。一个状态机或一个区域只能有一个初始伪状态。终止伪状态一个带圆圈的实心黑圆点表示状态机的终点。可以有多个终止伪状态。选择伪状态一个菱形表示根据守卫条件在不同迁移中选择一条。比如“支付结果”选择伪状态根据“支付成功”和“支付失败”两个守卫条件分别迁移到不同状态。合并伪状态也是菱形表示多条迁移汇聚到一点后再统一迁出。和选择的区别是选择是“一对多”合并是“多对一”。历史伪状态一个带 H 的圆圈表示回到复合状态时恢复到上次离开时的子状态。这个在复杂状态机中很有用但实际业务系统中用得不多因为业务状态通常需要明确指定而不是“恢复到上次”。伪状态的使用有个原则能用简单迁移表达的就不要用伪状态。我见过有人把简单的二选一迁移硬是画成选择伪状态结果图反而更复杂了。伪状态是为了解决特定问题而存在的不是为了炫技。3. 从零开始画一张状态机图3.1 第一步识别对象和状态清单画状态机图的第一步不是打开工具而是拿一张纸把对象的所有可能状态列出来。这一步的关键是穷举不要遗漏任何状态。以订单为例状态清单可能是待支付、已支付、已发货、已签收、已完成、已取消、退款中、已退款、已关闭。列完之后对每个状态问三个问题这个状态是怎么进入的在这个状态里要做什么怎么离开这个状态这里有个经验状态清单要和数据库的状态字段对齐。如果你的订单表里有一个 status 字段枚举值是 0-8那么状态机图里的状态应该和这些枚举值一一对应。如果状态机图里的状态比数据库枚举多说明有些状态是“逻辑状态”而不是“持久化状态”如果少说明数据库里有状态没有被建模。这两种情况都需要确认是否合理。3.2 第二步梳理迁移关系状态列完之后开始梳理迁移。对每个状态列出所有可能的触发事件和对应的目标状态。这一步建议用表格来做比直接画图更清晰。源状态事件守卫条件目标状态动作待支付支付成功金额匹配已支付更新支付时间待支付取消订单无已取消记录取消原因待支付超时超过30分钟已关闭释放库存已支付发货库存充足已发货记录物流单号已发货确认收货无已签收更新签收时间已签收完成无已完成触发结算已支付申请退款未发货退款中冻结金额退款中退款成功渠道返回成功已退款更新退款时间退款中退款失败渠道返回失败已支付解冻金额这张表就是状态机图的“数据源”。表梳理清楚了画图就是机械劳动。我强烈建议先做表再画图因为表格更容易发现遗漏和矛盾。比如你可能会发现“已取消”状态没有任何迁出迁移这是对的因为取消是终态但如果你发现“已完成”状态还有迁出迁移那就要问清楚什么情况下已完成订单还能变。3.3 第三步用工具画图工具选择上PowerDesigner、StarUML、PlantUML、draw.io 都可以。PowerDesigner 适合企业级建模能和数据库设计联动PlantUML 适合用代码生成图方便版本管理draw.io 适合快速画草图。如果你用 PlantUML下面是一段可以直接用的代码startuml [*] -- 待支付 待支付 -- 已支付 : 支付成功 待支付 -- 已取消 : 取消订单 待支付 -- 已关闭 : 超时[30min] 已支付 -- 已发货 : 发货 已支付 -- 退款中 : 申请退款[未发货] 已发货 -- 已签收 : 确认收货 已签收 -- 已完成 : 完成 退款中 -- 已退款 : 退款成功 退款中 -- 已支付 : 退款失败 已取消 -- [*] 已关闭 -- [*] 已完成 -- [*] 已退款 -- [*] enduml这段代码生成的图可以直接嵌入文档。PlantUML 的好处是图是“代码化”的改起来方便而且可以进 Git 做版本管理。我现在的项目里状态机图基本都用 PlantUML 维护评审时直接看代码 diff 就行。如果你用 draw.io建议把状态按生命周期从左到右排列初始状态在左终止状态在右这样图的可读性最好。迁移线尽量不要交叉如果交叉不可避免用“桥接”符号表示。3.4 第四步评审和验证图画完之后一定要做两件事走查所有路径和检查状态可达性。走查所有路径的意思是从初始状态出发沿着每一条可能的迁移路径走到终止状态看看有没有走不通的路径或者意料之外的路径。比如“待支付→已支付→已发货→已签收→已完成”是一条正常路径“待支付→已取消”是一条取消路径“待支付→已支付→退款中→已退款”是一条退款路径。每条路径都要能走通。检查状态可达性是指每个状态都必须能从初始状态到达也必须能到达某个终止状态。如果某个状态从初始状态不可达说明它是“孤岛状态”要么是多余的要么是漏了迁移。如果某个状态无法到达终止状态说明它是“死胡同状态”对象进入这个状态后就出不来了这通常是设计缺陷。我见过一个真实案例某系统的订单状态机图里有一个“审核中”状态但没有任何迁移指向它也没有任何迁移从它出发。开发照着图实现后这个状态永远不会被触发但代码里又留着这个分支后来被安全扫描扫出来当作“僵尸代码”。所以评审时一定要做可达性检查。4. 状态机图在实际项目中的常见坑4.1 状态爆炸当状态数量失控时怎么办状态爆炸是状态机图最常见的坑。一个订单系统如果支付方式有 3 种、订单类型有 4 种、配送方式有 2 种组合起来就是 24 种状态。如果每种组合都建一个状态图就没法看了。解决状态爆炸的核心思路是分离关注点。支付方式、订单类型、配送方式这些维度不应该混在状态里而应该作为状态机的“上下文”或“参数”。状态只描述生命周期阶段不描述业务属性。比如“待支付”状态不管是什么支付方式、什么订单类型都是“待支付”。支付方式的不同只影响“支付成功”这个事件的处理逻辑不影响状态本身。如果确实需要区分可以用复合状态或区域。比如“订单处理中”复合状态内部支付区域有“待支付/已支付/已退款”物流区域有“未发货/已发货/已签收”。两个区域并行状态数量从 24 种降到 6 种。4.2 守卫条件写不清楚迁移逻辑的模糊地带守卫条件是迁移箭头方括号里的布尔表达式比如[金额匹配]、[库存充足]、[超过30分钟]。守卫条件写不清楚是状态机图的另一个常见问题。我见过有人写[条件满足]这种守卫条件这等于没写。守卫条件必须是可判定的、明确的。[金额匹配]要说明匹配什么金额是订单金额和支付金额一致还是支付金额大于等于订单金额[超过30分钟]要说明从什么时间点开始算是从订单创建时间还是从进入待支付状态的时间守卫条件的另一个坑是互斥性。如果同一个事件有多个迁移守卫条件必须互斥否则状态机不知道走哪条。比如“支付结果”事件如果两个迁移的守卫条件分别是[金额0]和[金额0]那金额等于 0 时两条都满足就冲突了。正确的做法是[金额0]和[金额0]或者用选择伪状态明确优先级。4.3 动作和活动的混淆什么时候该用哪个动作Action和活动Activity的区别是状态机图里最容易混淆的概念之一。动作是原子性的、瞬时的、不可中断的写在迁移箭头上格式是事件/动作。比如支付成功/更新订单状态这个“更新订单状态”应该是一个数据库更新操作执行时间在毫秒级。活动是可持续的、可中断的写在状态内部用do/活动名表示。比如“退款中”状态的do/等待退款渠道返回这个等待可能持续几秒到几天期间如果收到“取消退款”事件可以中断等待迁移到其他状态。混淆的后果是如果把一个耗时操作写成动作状态机会被阻塞整个系统卡住如果把一个瞬时操作写成活动状态机会多出一个不必要的状态增加复杂度。我的判断标准是执行时间超过 1 秒的操作一律建模为活动执行时间在毫秒级的操作建模为动作。4.4 状态机图和数据库状态字段的同步问题状态机图是设计文档数据库状态字段是实现。两者不同步是项目中最常见的“文档腐化”问题。我见过一个项目状态机图上有 8 个状态数据库 status 字段有 10 个枚举值多出来的两个是开发临时加的“中间状态”。结果测试按状态机图写用例漏测了这两个中间状态上线后出了 bug。解决这个问题的办法是把状态机图作为状态字段的唯一权威来源。数据库 status 字段的枚举值必须和状态机图上的状态一一对应任何新增状态都必须先更新状态机图再改数据库。可以用代码生成的方式从状态机图定义生成数据库枚举和状态迁移校验代码这样两者永远不会不同步。5. 状态机图进阶复合状态与区域实战5.1 用复合状态简化复杂订单模型回到订单的例子。如果订单同时有支付和物流两条线用平铺状态机会得到“待支付未发货”“已支付未发货”“已支付已发货”“已签收已完成”等组合状态。用复合状态和区域可以这样建模“订单处理中”复合状态内部有两个区域。支付区域待支付 → 已支付 → 已退款。物流区域未发货 → 已发货 → 已签收。两个区域并行执行互不干扰。当支付区域到达“已支付”且物流区域到达“已签收”时复合状态整体迁移到“已完成”。这样建模的好处是状态数量从组合爆炸的 N×M 降到 NM图的可读性大幅提升。而且支付和物流的逻辑分离修改支付逻辑不会影响物流逻辑。5.2 区域之间的同步与通信区域之间虽然是并行的但有时候需要同步。比如“支付区域到达已支付”是“物流区域开始发货”的前提条件。这种同步可以用守卫条件来实现物流区域的“发货”迁移加上守卫条件[支付区域.已支付]。如果同步关系比较复杂可以用入口点Entry Point和出口点Exit Point。入口点是复合状态边界上的一个小圆圈表示从外部进入复合状态时直接进入某个子状态。出口点类似表示从某个子状态直接退出复合状态。这两个元素在实际项目中用得不多但在复杂状态机中能解决特定的同步问题。5.3 历史状态的使用场景与限制历史状态History State表示回到复合状态时恢复到上次离开时的子状态。画法是圆圈里写 H。浅历史Shallow History只恢复直接子状态深历史Deep History恢复所有嵌套子状态。历史状态适合“暂停/恢复”类场景。比如一个游戏角色有“站立”“行走”“奔跑”“跳跃”等状态玩家按暂停键后角色进入“暂停”状态再按恢复键应该回到暂停前的状态。这时候用历史状态就很合适。但历史状态在业务系统中要慎用。因为业务状态通常需要明确指定而不是“恢复到上次”。比如订单退款后应该明确回到“已支付”还是“已取消”而不是“上次离开时的状态”。如果业务规则不明确用历史状态会引入不确定性。6. 常见问题速查与排查技巧6.1 状态机图评审时最常被问的五个问题第一个问题“这个状态怎么进入”如果图上没有指向该状态的迁移说明状态不可达。第二个问题“这个状态怎么退出”如果没有从该状态出发的迁移说明是死胡同。第三个问题“这个事件在多个状态下都有迁移行为一致吗”如果不一致需要明确说明。第四个问题“守卫条件互斥吗”如果不互斥需要加优先级或改条件。第五个问题“动作执行失败怎么办”如果动作可能失败需要建模失败后的迁移。6.2 状态迁移遗漏的排查方法排查迁移遗漏最有效的方法是事件驱动法列出所有可能的事件然后对每个事件问“这个事件在每个状态下会发生什么”。如果某个事件在某个状态下没有定义迁移要么是遗漏了要么是明确忽略可以画一个“忽略”的自迁移。另一个方法是路径覆盖法从初始状态到每个终止状态列出所有可能的路径检查每条路径是否合理。如果发现某条路径走不通说明中间有迁移遗漏。6.3 状态机图与代码实现的一致性保障保障一致性最有效的手段是代码生成。用 PlantUML 或自定义 DSL 定义状态机然后生成状态迁移校验代码。比如生成一个OrderStateMachine类里面有canTransfer(from, event, to)方法业务代码在状态变更前调用这个方法校验。如果不用代码生成至少要做到状态枚举和迁移表在代码中集中定义不要散落在各个 Service 里。我见过一个项目状态迁移逻辑散落在 20 多个 Service 方法里后来要加一个“风控拦截”状态改了 3 天才改完还漏了两处。集中定义后加状态只需要改一个文件。6.4 工具选型对比PowerDesigner、StarUML、PlantUML、draw.io工具适合场景优点缺点PowerDesigner企业级建模、数据库联动功能全面、支持正向反向工程重、贵、学习曲线陡StarUML个人/小团队建模界面友好、支持多种 UML 图收费、插件生态一般PlantUML代码化建模、版本管理纯文本、Git 友好、免费需要学语法、样式调整麻烦draw.io快速草图、文档嵌入免费、易用、导出格式多不适合大型模型、无校验我的建议是个人学习用 draw.io 或 StarUML团队协作用 PlantUML企业级建模用 PowerDesigner。PlantUML 最大的优势是图即代码评审时看 diff 就行不用打开工具。7. 我在实际项目中的几点体会状态机图这个东西画出来不难画好很难。我做了这么多年项目最大的体会是状态机图的价值不在于图本身而在于画图过程中逼着团队把状态和迁移想清楚。很多团队不画状态机图直接写代码结果状态迁移逻辑散落在各处改一个状态要翻遍整个代码库。画状态机图的过程就是一次强制性的逻辑梳理。另一个体会是状态名一定要用业务语言不要用技术语言。我见过有人把状态写成“STATUS_1”“STATUS_2”这种状态名没有任何意义。状态名应该是“待支付”“已发货”这种业务人员能看懂的语言。状态机图是给业务、开发、测试三方看的不是给机器看的。最后分享一个小技巧状态机图画完后让测试同学照着图写用例。如果测试同学能照着图写出完整的用例说明图是清晰的如果测试同学问了一堆问题说明图里有模糊地带。这个方法比任何评审都有效因为测试同学的思维方式就是“找漏洞”他们能发现开发发现不了的问题。状态机图不是银弹它只适合“单个对象有明确生命周期”的场景。如果你的场景是“多个对象协作完成一个流程”那应该用时序图或活动图。选对图种比画好图更重要。