企业官网建设流程全解析

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 再定事件：每个状态下能发生什么

状态定完后，逐个状态列出它能响应的事件。待支付状态下能响应的事件有：用户支付成功、用户取消订单、超时未支付、系统风控拦截。已支付状态下能响应的事件有：仓库发货、用户申请退款、系统自动审核通过。已发货状态下能响应的事件有：用户确认收货、物流签收回调、超时自动确认。

这一步的关键是穷举。我习惯用表格来整理，行是状态，列是事件，交叉点填写迁移目标和动作。这样能直观地看出哪些状态缺少事件（死状态）、哪些事件在多个状态下都能触发（需要守卫条件区分）、哪些迁移路径是业务上不允许的（需要显式禁止）。

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 StateMachineConfigurerAdapter<OrderStatus, OrderEvent> { @Override public void configure(StateMachineTransitionConfigurer<OrderStatus, 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-else，5到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这些文本化工具在这方面有天然优势，改几个字符就能更新，不需要打开绘图软件拖拽。

状态图这个工具，入门容易精通难。画出一张能看的图不难，画出一张能指导实现、能推导测试、能对齐认知的图，需要大量的实践和踩坑。我到现在也不敢说每张状态图都画得完美，但至少每次画之前都会问自己：这个状态真的需要独立存在吗？这条迁移的守卫条件是不是太重了？异常路径覆盖全了吗？这三个问题问下来，图的质素通常不会太差。