状态机图

状态机图

状态机图强调对象有哪些状态、如何合法迁移，适合订单/工单状态。构图AI 可生成可编辑手绘状态图。

登录可免费体验 1 次；VIP 期内不限制日常画图；导出 PNG / SVG / .excalidraw。

什么时候用

• 电商与交易：待支付、已支付、发货中、已完成、已取消、退款中。
• 工单与任务：待办、进行中、阻塞、完成、归档。
• 设备与连接：离线、连接中、在线、故障、维护。
• 产品规则对齐：先画允许的迁移，再写接口与单测，避免「线上出现非法状态」。

若你要表达的是多人协作步骤而非对象状态，用流程图；若要表达服务调用顺序，用时序图；若只是排里程碑日期，用时间线。状态机的关键词是「可停留的状态 + 触发事件」。

核心元素

元素	说明
初始态	对象创建后的起点，常用特殊椭圆标记
中间态	圆角矩形，名称应稳定、可枚举
终态	完成、取消、关闭等不再离开的状态
迁移箭头	旁注触发事件（支付成功、超时、用户取消）
守卫条件（可选）	如「库存充足才可发货」，写在事件旁

设计原则：状态互斥且完备——任意时刻对象只落在一个状态；业务上该出现的状态都要有名。状态名用名词或形容词短语，避免写成「调用支付接口」这类动作。

排版规则（状态机专用）

1. 主成功路径成环或成带：待支付→已支付→发货中→已完成排成顺读主链。
2. 取消/失败沉到一侧：用另一色系，避免与主链交叉缠绕。
3. 回流箭头走外侧：重试、退回不要穿过状态框中心。
4. 状态数超过 8 个就分区：交易态与售后态可分两框，或拆成两张图。

反例：把「校验参数、调支付、写库、发 MQ、更新缓存」五个瞬时步骤画成五个状态——那是流程，不是状态机。正确状态应是「待支付 / 支付中 / 已支付」等可查询业务事实，瞬时步骤写在事件或时序图里。

Prompt 好坏对比

	示例	为什么
差	画订单状态图	缺状态列表与事件，易漏取消/退款
差	把所有内部 flag 都画成状态	状态爆炸，无法评审
好	画订单状态机：待支付、已支付、发货中、已完成、已取消；含超时关单与支付后取消	状态可枚举，事件齐全
好	画工单状态：待办→进行中→阻塞→完成，阻塞可回到进行中	回流规则清楚

落地前可用状态机反推测试用例：每个迁移对应至少一条用例，非法迁移也要有否定用例，图与测试才能互相印证。

常见错误

1. 状态与动作混写：把瞬时操作当成状态；状态应是可停留、可查询的业务事实。
2. 缺少事件标注：箭头无文字，读者不知道如何触发迁移，研发无法落地。
3. 非法捷径：从图上允许「已完成直接回待支付」，与业务规则冲突。
4. 单排直线排版：状态一多就挤；可用两行蛇形或环形布局，终态/异常态用不同色系区分。
5. 终态不终：已完成还能随便改回进行中却不说明守卫条件，会误导实现。

与相邻图类型的区别

维度	状态机图	流程图	时间线
核心	状态 + 事件	步骤 + 判断	时间点上的事件
是否可回流	常见（重试、取消）	较少强调回流	一般单向时间前进
对象视角	强（一个主体）	弱（过程视角）	弱（事件序列）
典型	订单生命周期	下单操作步骤	版本里程碑

并发状态（如支付中同时可取消）要用守卫条件写清优先级，或拆成清晰的互斥态，避免实现里用一堆布尔标志偷偷表示「子状态」。

用构图AI怎么画

选择「状态机图」，直接列出状态与关键事件，例如：「画订单状态机：待支付、已支付、发货中、已完成、已取消，含超时关单」。生成后逐条核对迁移是否合法，再导出给评审。可对照订单状态示例页检查是否漏了售后回流。

构图AI 共 12 种技能，可与流程图、时序图配合：流程讲怎么做，状态机讲对象处于哪，时序讲谁调用谁。

相关：状态流转示例 · 电商订单示例 · 电商流程指南 · 使用此技能画图

最后提醒：若状态只有三个且全是直线前进，考虑是否根本不需要状态机，流程图可能更合适。

此外，建议把本页与站内示例对照着练两次：第一次照抄结构，第二次换成你的业务词。两轮之后，你对该图类型的边界会比只读文档清晰得多。

事件命名规范

推荐「业务名词 + 过去分词/结果」：PaymentSucceeded、ShipmentDispatched，而不是 doPay、clickButton。事件名应能进入日志与埋点，使图、代码、观测一致。

若同一事件在不同状态下有不同含义，说明事件切分不够细，或你实际需要的是流程图里的活动，而不是状态迁移。

测试用法

把每个合法迁移写成集成测试名：pending_to_paid_on_payment_succeeded。非法迁移则断言拒绝。状态机图此时不再是插图，而是测试大纲。