状态机图适合描述“同一个业务对象会处于哪些状态，以及什么事件让它迁移”，它比普通流程图更关注状态持续时间、可触发事件和禁止迁移。画法不是把所有页面连起来，而是先列状态，再写事件和条件，最后为每条迁移补结果。下面用“订阅续费”案例演示如何从状态表画到可评审的状态机图。
先列迁移表，再用墨刀流程图表示节点和连线，能更早发现条件重叠、无法退出的状态和遗漏的异常分支。
先区分对象、状态和事件
本例描述一项续费任务，待续费、扣款中、续费成功、扣款失败和已取消是它的状态；用户点击“立即续费”、系统发起扣款、支付回调成功、重试次数耗尽是事件。页面、按钮和接口都不是状态本身。先把三类词分开，团队才不会把“点击支付”画成一个长期状态，或把“订单详情页”误当成业务节点。
| 类别 | 订阅续费例子 | 写法提示 |
|---|---|---|
| 对象 | 订阅订单 S-1024 | 一张图只描述一个主要对象 |
| 状态 | 待续费、扣款中、续费成功 | 用能持续一段时间的名词描述 |
| 事件 | 发起续费、支付成功回调 | 用动作描述触发迁移 |
| 条件 | 余额足够、重试次数小于3 | 写在迁移线上，避免藏在备注里 |
把迁移规则写成表，再画图
先用表格检查互斥和遗漏，再在墨刀流程图中把状态画成节点、事件画成连线标签。以续费任务 S-1024 为例；以下“最多重试 3 次”仅是本例规则，实际需由业务确认：
| 当前状态 | 事件/条件 | 下一状态 | 用户可见结果 |
|---|---|---|---|
| 待续费 | 到期前自动扣款 | 扣款中 | 显示处理中，不允许重复发起 |
| 扣款中 | 支付回调成功 | 续费成功 | 更新到期日并生成回执 |
| 扣款中 | 支付失败且可重试 | 扣款失败 | 说明原因并显示重试入口 |
| 扣款失败 | 重试次数小于3且用户确认 | 扣款中 | 保留订单号，避免重复创建 |
| 扣款失败 | 重试次数达到3 | 待人工处理 | 提示联系客服，不再自动扣款 |
| 待续费 | 用户取消自动续费 | 已取消 | 终止本次续费任务；订阅权益期限另按业务规则处理 |
三步画出可评审的状态机图
- 圈定生命周期：写出对象从创建到结束会经历的最小状态，暂时不放页面和接口细节。
- 补迁移条件：为每条连线写唯一事件，必要时增加权限、时间、金额或重试次数条件。
- 走查异常：逐个状态问“事件失败、重复触发、回调延迟、用户退出时怎么办”，把有业务意义的分支画出来。
一张图太大时按对象拆分，例如把支付对象和订阅对象分开，再用订单号或回调事件标出关联。不要把每个视觉弹窗都加成状态，否则图会失去业务判断价值。
状态机图最容易漏的边界
重复事件：用户连续点击续费，系统应回到已有扣款中状态还是创建两笔订单？在迁移规则中写幂等键或禁止条件。
未知结果：支付请求超时不等于失败。可以增加“待确认”状态，允许查询结果后再决定成功或重试。
终止后的动作：已取消或续费成功是否允许撤销？如果不允许，明确拒绝原因；如果允许，写出逆向迁移和权限条件。
交付给产品、设计和研发的材料
最终包应包括状态机图、迁移表、事件命名、状态对应的用户文案，以及仍需确认的规则。评审时先从最危险的迁移开始：扣款中刷新、回调延迟、重复重试和取消后再次续费。页面原型可以引用状态机节点，但不要用页面数量代替状态覆盖；研发实现后还应按迁移表编写接口和测试用例。
给每条迁移补上守卫条件
状态机图最有价值的部分往往不是节点数量，而是连线上的条件。把“扣款失败”拆成“可重试”和“不可重试”两条迁移，条件写清余额、重试次数、支付回调或人工介入。条件重叠时应明确优先级，或回到业务规则重新定义为互斥条件；否则同一事件可能匹配不同迁移，导致不同服务得到不同结果。
| 迁移 | 守卫条件 | 应禁止的动作 |
|---|---|---|
| 待续费→扣款中 | 订单未过期且没有进行中的扣款 | 禁止重复创建支付单 |
| 扣款中→待确认 | 请求超时且未收到明确失败 | 禁止直接展示“扣款失败” |
| 待确认→续费成功 | 查询到唯一成功回执 | 禁止再次扣款 |
从图得到测试用例
每条迁移至少对应一个正向用例和一个边界用例。比如“扣款失败且可重试”要验证重试后仍使用同一订阅订单；“超时待确认”要验证刷新页面不会把状态退回待续费。测试标题用“当前状态＋事件＋条件＋预期状态”表达，研发可以直接放进测试计划。
当状态机需要和页面原型一起评审时，让产品先讲对象生命周期，再让设计展示对应状态，最后让研发确认事件和接口。若有人只能根据页面颜色判断状态，说明图或文案还不够明确。
状态、页面和接口状态不能直接画等号
一个业务状态可能对应多个页面：扣款中既能出现在付款页，也能出现在订单详情页；一个页面也可能展示多种状态。HTTP 请求成功只说明接口请求完成，不一定表示扣款成功。先确定业务状态的唯一来源，再决定页面如何读取和解释结果。
图中再加一列“由谁确认”：用户点击只发起续费，支付结果由回执或查询确认，超时只进入待确认。刷新页面应读取最新业务状态，不得重新发起扣款。将这些约定写入接口和测试说明，才能让状态机真正约束实现。
下一步在墨刀流程图中先画待续费、扣款中、待确认和成功四个节点，沿着“请求超时—查询结果”走查一次，再补失败与取消分支；先确认迁移规则，再对应到页面状态。
