这个订单明明已经退款了怎么能再发货——当时运营把这样一个 bug 甩到我脸上的时候我刚从试吃订单项目的第一个版本里爬出来。那版代码很朴素一张订单表一个status字段0 待支付、1 已支付、2 配送中、3 已完成、4 已取消每个操作入口都写一段if (status xxx)的校验。结果就是支付回调、商家拒单、骑手送达、用户取消、超时任务五个入口往同一个字段上写谁都能改状态谁都不保证状态改得对。那段时间我意识到这类业务根本不是多写几个 if能解决的它缺的是一个能把允许怎么流转、不允许怎么流转从业务代码里抽出来的机制。后来我把整个试吃订单的状态流转全部重写底层换成了 Spring State Machine也就是 Spring 官方那套状态机框架。这篇文章就完整记录一下我是怎么用 Spring State Machine 给外卖试吃订单建模的包括状态和事件怎么定义、Guard 和 Action 怎么设计、持久化怎么处理以及上线之后踩到的那些坑。如果你是第一次接触状态机或者正要给订单类业务引入状态机这篇可以直接当参考。1. 试吃订单的真实业务链路为什么一个 status 字段扛不住先把业务场景说清楚。外卖试吃订单是平台营销的一种玩法用户可以用一个很低的价格甚至 0 元购买某道菜的试吃份。它跟普通外卖单最大的区别在于资格两个字——平台要控制每个用户只能试吃一次要校验用户是不是新客要限制同一家店同一道菜的试吃数量支付成功之后可能还要走退款商家端还有接单时限。这些规则叠加在订单生命周期上之后单纯的status字段就非常吃力了。1.1 试吃订单的完整状态清单我梳理下来的生命周期是这个样子WAIT_PAY待支付用户提交试吃订单生成一条待支付记录。付费试吃的用户在这里等付款0 元试吃的用户会由内部任务自动触发一笔 0 元支付。PAID已支付/待接单支付回调验签通过或者 0 元支付流程完成订单进入待商家接单状态。PREPARING备餐中商家接单后开始制作。DELIVERING配送中骑手取餐完成正在配送。COMPLETED已完成用户确认收货或者系统超时自动确认。CANCELLED已取消支付超时被系统取消或者用户在商家接单前主动取消。REFUNDED已退款支付后发生取消商家拒单、用户取消等场景钱退回去订单终态。这个清单本身不难难的是这 7 个状态之间哪些转化是合法的。试吃订单比普通订单多了一层退款的尾巴又多了一层资格限制的前置组合起来之后非法路径远比合法路径多已支付订单不能直接完成备餐中的订单不能贸然取消已取消的订单绝对不能再次支付成功COMPLETED 和 REFUNDED 作为终态不能有任何出边。1.2 用 if/else 维护流转矩阵的崩溃现场第一版代码的典型写法是这样// 支付回调入口 if (order.getStatus() 0) { // 校验支付签名、校验资格、扣减试吃名额、改状态为已支付... } else if (order.getStatus() 1) { // 重复回调直接返回成功 } else { // 这时候订单是已取消或已退款怎么办 // 有人写日志有人抛异常有人直接把订单翻回已支付 }问题不在 if 本身而在入口太多。支付回调、商家接单、拒单、骑手取货、确认收货、用户取消、定时任务每个入口都要重复一遍当前状态合不合法的判断漏一个就是线上事故。更麻烦的是这种判断散落在 Service 层各处产品说需要加一个资格预审状态的时候你得把所有入口都翻开看一遍看哪个 if 需要改。这不是代码质量问题是建模方式的问题你把流转规则和业务逻辑耦合在同一层了。所以第二版我做了一个很关键的决定把状态流转规则集中收敛用 Spring State Machine 把这些规则变成显式的状态 事件 守卫 动作业务代码只负责发送事件规则本身由状态机统一裁决。2. 状态机建模预备课先把状态、事件、流转矩阵定死真正写配置之前有一件事必须做把产品、运营、后端拉到一起在白板上把所有状态和合法流转画出来。这一步看起来浪费时间实际上能消灭 80% 的歧义。比如商家拒单之后订单去哪这个问题我们当时就吵了两轮——有人觉得直接取消有人觉得要退款最后因为试吃订单收了用户的 1 块钱才统一成进入 REFUNDED。这类业务歧义如果等到写代码时才发现改起来成本高得多。2.1 状态和事件的枚举定义状态枚举和事件枚举是状态机的骨架我直接贴代码public enum OrderState { WAIT_PAY(待支付), PAID(已支付/待接单), PREPARING(备餐中), DELIVERING(配送中), COMPLETED(已完成), CANCELLED(已取消), REFUNDED(已退款); private final String desc; OrderState(String desc) { this.desc desc; } }public enum OrderEvent { PAY_SUCCESS(支付成功), PAY_TIMEOUT(支付超时), MERCHANT_ACCEPT(商家接单), MERCHANT_REJECT(商家拒单), START_DELIVERY(开始配送), CONFIRM_RECEIPT(确认收货), AUTO_CONFIRM(超时自动确认), USER_CANCEL(用户取消), REFUND(退款); }这里有一个设计原则要强调事件命名必须站在外部发生了什么的角度而不是站在内部要改成什么状态的角度。比如支付回调到达事件叫PAY_SUCCESS不叫UPDATE_TO_PAID。因为同一个外部事件可能在不同状态下触发不同转移比如用户取消在WAIT_PAY是直接取消在PAID是取消并退款如果事件命名成改成某个状态语义就拧了。2.2 流转矩阵与守卫条件我们最终确认的合法流转如下这也是后面所有配置的唯一事实来源当前状态事件目标状态核心守卫条件WAIT_PAYPAY_SUCCESSPAID支付回调验签通过金额与订单一致用户满足试吃资格未重复支付WAIT_PAYPAY_TIMEOUTCANCELLED订单确实超时未支付无支付流水WAIT_PAYUSER_CANCELCANCELLED用户主动取消校验归属PAIDMERCHANT_ACCEPTPREPARING商家接单窗口未过期门店营业中试吃名额未超卖PAIDMERCHANT_REJECTREFUNDED商家在窗口期内拒单触发退款PAIDUSER_CANCELREFUNDED支付未出餐用户取消触发退款PREPARINGSTART_DELIVERYDELIVERING骑手已取餐配送单状态为运输中PREPARINGUSER_CANCELREFUNDED仅在未出餐时允许出餐后需走客服异常流程DELIVERINGCONFIRM_RECEIPTCOMPLETED骑手上报送达或用户点击确认DELIVERINGAUTO_CONFIRMCOMPLETED配送完成超时时间达到这张表定下来之后你会很直观地看到状态机的价值它把什么时候能做什么事变成了可查、可测、可评审的材料而不是藏在代码里的一堆 if。反过来如果表里出现了一个当前状态不明的格子那就是业务规则的漏洞要在建模阶段补掉而不是等上线后救火。3. Spring State Machine 选型与核心机制拆解确定要用状态机之后团队内部其实还讨论过几条路自己写一个状态模式的状态类、用 Flowable 这类工作流引擎、还是用 Spring State Machine。最后选了 Spring State Machine核心原因是它的概念粒度刚好匹配订单业务。3.1 五个核心概念用外卖场景一次讲透Spring State Machine 里最核心的概念就五个我用外卖场景类比一下State状态就是订单当前在哪个环节对应前面的OrderState枚举。Event事件外部发生了什么对应OrderEvent枚举比如骑手取了餐。Transition转移从某个状态收到某个事件后允许走到哪个目标状态也就是矩阵里的每一行。Guard守卫转移的阀门。事件到达只是触发Guard 决定这个转移到底允不允许执行。比如MERCHANT_ACCEPT事件到达Guard 要查商家接单窗口是否过期。Action动作转移通过后执行的副作用。比如支付成功之后写支付流水、发营销短信、通知商家。还有一个贯穿全局的Listener监听器它不参与流转决策只负责围观状态变了、事件没被接受、机器报错了都能在 Listener 里感知到。这个对排障非常重要后面专门讲。3.2 为什么不自己写状态模式也不用工作流引擎先说自研状态模式State Pattern。它的思路是每个状态一个类每个类里声明自己允许哪些操作。这套方案在类数量少、流转关系稳定的系统里没问题但试吃订单这种 7 个状态、9 种事件、十几条流转的场景一旦开始叠 Guard 和 Action类会膨胀得很厉害而且流转关系分散在多个状态类里全局视角反而弱了。Spring State Machine 把流转集中在一个配置类里新同学看配置就能懂全链路。再说 Flowable 这类工作流引擎。它是给审批流、工单流设计的有人工任务、会签、BPMN 流程文件能力很强但也重。订单状态流转本质是状态 事件 规则不是流程 任务 人硬塞进 BPMN 里反而别扭部署和运维成本也高。Spring State Machine 轻量依赖少和 Spring Boot 天然集成对订单系统来说是刚好够用的中间选项。3.3 依赖与版本我们当时用的 Spring Boot 2.7.x状态机依赖是dependency groupIdorg.springframework.statemachine/groupId artifactIdspring-statemachine-core/artifactId version3.2.1/version /dependency如果是 Spring Boot 3 的新项目用 4.x 系列。注意 4.x 对配置 API 有调整老项目升级时要额外核对配置类的写法。4. 用 StateMachineFactory 搭建可复用的订单状态机配置状态机之前先回答一个关键问题项目中应该用EnableStateMachine还是EnableStateMachineFactory这两个注解的差别非常重要。EnableStateMachine会在 Spring 容器里注册一个全局单例的状态机 Bean。这种模式适合全系统只有一条流程、状态天然唯一的场景比如发布流程。但订单完全不同——每个订单都有自己的状态如果共用同一个状态机实例订单 A 的支付事件会把订单 B 的状态也带偏这是灾难。所以必须用EnableStateMachineFactory它注册的是一个StateMachineFactory你可以为每个订单getStateMachine(orderId)创建独立的实例。每个实例内部持有自己的状态互不干扰。4.1 状态机配置类Configuration EnableStateMachineFactory public class TrialOrderStateMachineConfig extends StateMachineConfigurerAdapterOrderState, OrderEvent { Autowired private TrialEligibilityGuard trialEligibilityGuard; Autowired private PayTimeoutGuard payTimeoutGuard; Override public void configure(StateMachineStateConfigurerOrderState, OrderEvent states) throws Exception { states.withStates() .initial(OrderState.WAIT_PAY) .states(EnumSet.allOf(OrderState.class)); } Override public void configure(StateMachineTransitionConfigurerOrderState, OrderEvent transitions) throws Exception { transitions .withExternal() .source(OrderState.WAIT_PAY).target(OrderState.PAID) .event(OrderEvent.PAY_SUCCESS) .guard(trialEligibilityGuard) .action(paySuccessAction()) .and() .withExternal() .source(OrderState.WAIT_PAY).target(OrderState.CANCELLED) .event(OrderEvent.PAY_TIMEOUT) .guard(payTimeoutGuard) .action(payTimeoutAction()) .and() .withExternal() .source(OrderState.WAIT_PAY).target(OrderState.CANCELLED) .event(OrderEvent.USER_CANCEL) .action(cancelAction()) .and() .withExternal() .source(OrderState.PAID).target(OrderState.PREPARING) .event(OrderEvent.MERCHANT_ACCEPT) .guard(merchantAcceptGuard()) .action(prepareAction()) .and() .withExternal() .source(OrderState.PAID).target(OrderState.REFUNDED) .event(OrderEvent.MERCHANT_REJECT) .action(refundAction()) .and() .withExternal() .source(OrderState.PAID).target(OrderState.REFUNDED) .event(OrderEvent.USER_CANCEL) .action(refundAction()) .and() .withExternal() .source(OrderState.PREPARING).target(OrderState.DELIVERING) .event(OrderEvent.START_DELIVERY) .action(startDeliveryAction()) .and() .withExternal() .source(OrderState.PREPARING).target(OrderState.REFUNDED) .event(OrderEvent.USER_CANCEL) .guard(notPreparedGuard()) .action(refundAction()) .and() .withExternal() .source(OrderState.DELIVERING).target(OrderState.COMPLETED) .event(OrderEvent.CONFIRM_RECEIPT) .action(completeAction()) .and() .withExternal() .source(OrderState.DELIVERING).target(OrderState.COMPLETED) .event(OrderEvent.AUTO_CONFIRM) .action(completeAction()); } }配置里的 Guard 和 Action 我都是以 Bean 的方式注入的这里有个好处它们自己可以依赖 Service、Mapper 去做真正的业务判断和副作用操作状态机配置只负责编排。4.2 Guard 的写法把能不能转收敛到一处以试吃资格守卫为例它管的是最核心的营销规则Component public class TrialEligibilityGuard implements GuardOrderState, OrderEvent { Autowired private TrialOrderMapper orderMapper; Autowired private UserTrialQuotaMapper quotaMapper; Override public boolean evaluate(StateContextOrderState, OrderEvent context) { Long orderId context.getMessageHeader(orderId); TrialOrder order orderMapper.selectById(orderId); if (order null) { return false; } // 用户是否还有试吃资格首单/限购 int usedCount quotaMapper.countUsedQuota(order.getUserId(), order.getShopId()); if (usedCount 1) { return false; } // 支付金额与订单应付金额是否一致试吃价可能是 0.01 元或 0 元 BigDecimal paidAmount context.getMessageHeader(paidAmount); return order.getPayAmount().equals(paidAmount); } }这里有个很重要的经验Guard 里只做判断绝对不要做有副作用的操作。比如扣减试吃名额这种动作不要放 Guard因为 Guard 返回 false 时整个转移被拒绝但你已经扣了名额数据就错了。扣名额要放到 Action 里并且要考虑转移失败回滚的问题。这一点后面踩坑部分还会展开。4.3 Action 的写法把转完之后干什么挂上去转账成功之后要写支付流水、发通知这些属于动作Component public class PaySuccessAction implements ActionOrderState, OrderEvent { Autowired private PayFlowMapper payFlowMapper; Autowired private MessageSender messageSender; Override public void execute(StateContextOrderState, OrderEvent context) { Long orderId context.getMessageHeader(orderId); String payNo context.getMessageHeader(payNo); payFlowMapper.insert(new PayFlow(orderId, payNo, TRIAL_PAY_SUCC)); messageSender.sendShopNotice(orderId, 你的试吃订单已支付请及时处理); } }注意Action 里的execute里面抛出的异常会被状态机捕获并包装成StateMachineError交给异常监听器处理。所以 Action 里如果调了外部 RPC一定要做好超时和异常兜底不能让外部抖动反过来破坏订单主流程。更稳妥的做法是把外部通知从 Action 里挪出去用 MQ 异步发送Action 只负责本地 DB 操作。我们二期就是这么改的订单主链路明显稳了。4.4 Service 层发事件的标准姿势业务层不需要关心状态机内部怎么流转只需要拿到机器、装好事件、发出去Service public class TrialOrderService { Autowired private StateMachineFactoryOrderState, OrderEvent stateMachineFactory; Autowired private TrialOrderMapper orderMapper; public boolean handlePayCallback(Long orderId, PayCallbackDto callback) { TrialOrder order orderMapper.selectById(orderId); if (order null) { return false; } // 从数据库当前状态重建机器避免内存状态不可信 StateMachineOrderState, OrderEvent machine rebuildMachine(orderId, order.getStatus()); MessageOrderEvent message MessageBuilder.withPayload(OrderEvent.PAY_SUCCESS) .setHeader(orderId, orderId) .setHeader(paidAmount, callback.getAmount()) .setHeader(payNo, callback.getOutTradeNo()) .build(); boolean accepted machine.sendEvent(message); if (!accepted) { log.warn(支付回调未被接受: orderId{}, currentState{}, orderId, machine.getState().getId()); return false; } // 状态机转移成功后订单状态在 Action 里已同步到 DB return true; } }这里有一个细节machine.sendEvent()返回的是事件是否被某个转移接受。如果返回 false代表当前状态下没有匹配的转移或者 Guard 没过。这个返回值要谨慎处理不能直接当成业务失败——它可能只是重复回调这种正常情况。后面我会讲怎么区分这两类情况。5. 持久化与重启恢复状态机最容易被低估的一环Spring State Machine 本身是内存模型状态存在对象实例里。订单系统是最典型的高并发 长生命周期 分布式多实例场景如果天真地把状态机实例常驻内存进程一重启全丢了。所以持久化是绕不开的一环。我先说结论不要试图把状态机实例养在 JVM 里订单量一大根本养不起。正确姿势是把状态机当用完即弃的编排工具——DB 里永远有一列status存订单当前状态每次要处理事件时根据 DB 里的当前状态重建一个状态机实例推进之后把新状态写回 DB实例随之丢弃。5.1 从 DB 状态重建状态机重建的代码长这样private StateMachineOrderState, OrderEvent rebuildMachine(Long orderId, OrderState currentState) { StateMachineOrderState, OrderEvent machine stateMachineFactory.getStateMachine(orderId.toString()); machine.stop(); machine.getStateMachineAccessor() .doWithAllRegions(access - access.resetStateMachine( new DefaultStateMachineContext(currentState, null, null, null))); machine.start(); return machine; }resetStateMachine把机器的当前状态直接设置成 DB 里读出来的状态然后start()。这样每次事件处理都基于DB 的最新状态不依赖任何内存里的旧实例。状态机的extendedState如果需要保留跨转移的数据比如试吃资格标记也可以在重建时一并塞回去但我们实测发现业务上下文放在 Message Header 里更干净、更不容易序列化出错所以最终只保留了一个状态字段。5.2 两种持久化路线我推荐第一种路线 ADB 只存 status 事件流水表。每个事件尝试都往流水表插一行from_state、to_state、event、operator、result状态机只管逻辑判定DB 的 status 列在 Action 里更新。这套方案简单、直观、好排查。我们生产环境就是这种方案。路线 B用 spring-statemachine-data-jpa 完整持久化 StateMachineContext。官方提供的 JPA 方案会把状态、事件、extendedState 快照都序列化存库适合需要完整回放、审计场景复杂的系统。代价是表结构复杂、读写开销大对订单这种高频场景来说偏重。我见过不少团队一上来就上路线 B觉得官方方案最全结果序列化和表结构把团队折腾得够呛。除非你确实需要回放全部事件流否则路线 A 已经能覆盖 99% 的订单场景状态列 流水表配合后面的乐观锁足够保证正确性。5.3 并发控制状态机管正确性数据库管幂等状态机有个天然的缺陷它本身不解决并发问题。支付回调和用户取消同时到达两个请求都读了 DB 状态为WAIT_PAY都重建机器都发事件理论上两个都能过。所以必须有一个底层的并发屏障。我们的做法是两件事叠加更新状态时用乐观锁SQL 长这样UPDATE trial_order SET status #{targetStatus} WHERE id #{orderId} AND status #{sourceStatus}受影响行数是 0 就说明状态被并发改了这次事件处理需要重试或者直接判定失败。事件流水表对同一订单的同一事件加唯一约束比如unique(order_id, event_name, event_no)。支付平台的重试回调来了之后第二条同样的事件流水插不进去天然实现了幂等。状态机的价值在于判定这次流转合不合法数据库的价值在于保证同一时刻只有一个流转能落地。两者各管一摊谁也替代不了谁。这一段是我最想让你记住的状态机不是银弹它解决的是流转规则的可维护性并发正确性还得靠数据库约束。6. 实测踩坑记录与回归测试清单最后这部分是我在真实上线过程中踩出来的每一条都对应过一次线上问题或差点上线的事故。6.1 坑一Guard 里抛异常比返回 false 难查十倍Guard 的evaluate方法抛了异常和返回 false 在现象上都是事件没被接受sendEvent 返回 false但排查难度完全不一样。返回 false 是正常的规则拒绝你预期得到 false抛异常则是系统错误但状态机默认不会把异常打出来甚至会吞掉一部分信息。我们第一次踩这个坑是在 Guard 里调了一个风控 RPC超时抛异常结果回调一直失败日志里却什么都看不到。经验Guard 里只做本地判断任何远程调用都别放进来。如果风控这类远程校验必须做放在 Action 里做并且 Action 里 catch 所有异常做降级和记录同时给stateMachineError监听器单独接告警。另外Guard 内部不要用 try/catch 把异常吞掉再返回 false那样会把系统错误伪装成规则拒绝排查时容易误导方向。6.2 坑二eventNotAccepted 是排查的核心入口当sendEvent返回 false 时你第一反应应该是去看eventNotAccepted里有没有打日志。这个监听器专门负责事件没被任何转移接受的场景Component public class OrderStateMachineListener extends StateMachineListenerAdapterOrderState, OrderEvent { Override public void eventNotAccepted(MessageOrderEvent event) { Long orderId event.getHeaders().get(orderId, Long.class); log.warn(事件未被接受: orderId{}, event{}, orderId, event.getPayload()); } Override public void stateMachineError(StateMachineOrderState, OrderEvent stateMachine, Exception exception) { log.error(状态机内部错误: {}, stateMachine.getId(), exception); // 这里接告警 } }这个 Listener 必须挂上并且eventNotAccepted日志里一定要带上订单号和事件名。没有它排查为什么回调失败只能靠翻流水表猜。有了它基本一眼就能定位是哪个状态收到了哪个不该来的事件。另外别忘了 Listener 是配置在configure(StateMachineConfigurationConfigurer)里的要和机器绑定不是随便一个 Bean 就能生效。6.3 坑三EnableStateMachine 的单例陷阱这个坑我们在技术方案评审时拦住了但值得单独说。如果你用的是EnableStateMachineSpring 容器里只有一个全局状态机 Bean。想象一下订单 A 和订单 B 同时调用stateMachine.sendEvent()两个事件被同一个实例处理实例的当前状态在事件之间会互相污染。一旦并发上来订单状态会彻底错乱。所以订单类业务必须用EnableStateMachineFactory每个订单拿到独立实例。还有一点StateMachineFactory.getStateMachine(String machineId)的 machineId 在同一个 factory 内是有缓存语义的同一个 id 可能复用到之前的实例。所以我们的做法是每次处理事件前都调用rebuildMachine(orderId, dbStatus)把状态重置为 DB 里的值避免复用带来的脏状态。这是配合 5.1 节的关键操作别忘了。6.4 坑四Action 里做事务和外部调用的先后顺序状态机的 Action 不支持事务语义它是执行动作的框架不是保证一致性的事务边界。我们最早的写法是把更新 DB 状态、写流水、发 MQ 通知全塞在一个 Action 里后来发现外部 MQ 抖动会导致 Action 抛异常异常被状态机吞掉状态没更新但流水已经写了数据又对不上了。现在的实际方案是Action 里只做本地数据变更更新 status、插流水外部通知全部发 MQ 异步处理。这样 Action 的失败面大幅缩小就算 MQ 发不出去有重试 Job 兜底。如果确实有必须和状态转移一起成功的外部调用那就老老实实做本地事务表 出站消息的可靠投递模式别指望状态机帮你协调。6.5 回归测试清单状态机的配置是集中式的这带来一个巨大的测试红利你可以用参数化测试把整张流转矩阵验证一遍。测试用例长这样SpringBootTest class StateMachineTransitionTest { Autowired private StateMachineFactoryOrderState, OrderEvent stateMachineFactory; ParameterizedTest CsvSource({ WAIT_PAY, PAY_SUCCESS, PAID, WAIT_PAY, PAY_TIMEOUT, CANCELLED, WAIT_PAY, USER_CANCEL, CANCELLED, PAID, MERCHANT_ACCEPT, PREPARING, PAID, MERCHANT_REJECT, REFUNDED, PREPARING, START_DELIVERY, DELIVERING, DELIVERING, CONFIRM_RECEIPT, COMPLETED, DELIVERING, AUTO_CONFIRM, COMPLETED }) void shouldMoveToTargetState(OrderState source, OrderEvent event, OrderState target) { StateMachineOrderState, OrderEvent machine stateMachineFactory.getStateMachine(UUID.randomUUID().toString()); machine.stop(); machine.getStateMachineAccessor() .doWithAllRegions(access - access.resetStateMachine( new DefaultStateMachineContext(source, null, null, null))); machine.start(); boolean accepted machine.sendEvent(MessageBuilder.withPayload(event).build()); Assertions.assertTrue(accepted); Assertions.assertEquals(target, machine.getState().getId()); } }除了合法的正向流转还要列一张非法组合清单做反向测试比如WAIT_PAY - START_DELIVERY必须返回 falseCOMPLETED - PAY_SUCCESS必须返回 false。这两张表共同构成状态机的行为基线后续任何人改配置跑一遍测试就能知道有没有破坏流转规则。上线前我还会手动核对几个关键点事件流水表有没有唯一约束eventNotAccepted和stateMachineError有没有接告警乐观锁更新 SQL 的 where 条件是不是同时带了 sourceStatus试吃资格扣减是不是放在 Action 而不是 Guard。这几个点都过了状态机这层基本就稳了。最后分享一个我个人的小习惯那张流转矩阵表我会一直贴在工位旁边。每次产品提加一个状态或者这里要允许取消我先在表上画画得出来再改配置画不出来就先和产品对齐。状态机给订单系统带来的最大改变不是代码写得更优雅了而是让业务规则第一次变成了一张看得见、说得清、测得了的图。这个价值比省掉几个 if 重要得多。