订单取消与出库撞车怎么办？用状态流转图核对业务规则

订单状态流转图不能只画“待发货→已发货→已完成”。真正需要在需求评审里说清的是：用户取消订单的同时，仓库开始出库，哪一个操作还能生效？答案要落实到当前状态、触发事件、允许条件、目标状态和失败后的处理，再分别走一遍两种先后顺序。

下面以已确认支付、单件商品、一次发货的履约订单为例。你可以在Boardmix 的 UML 绘图工具中把状态图、转换表和验收用例放在同一块画布，评审时沿着同一个订单核对。图帮助团队统一规则；真正阻止冲突操作的是业务系统对状态变更的校验和提交。

先划清对象：履约状态不等于支付状态

本例从“支付已确认、订单待履约”开始，到“已完成”或“已取消”结束。“已取消”表示这张履约订单停止出库，不表示钱已经退回。退款、售后、库存占用各有自己的处理过程，应通过订单号关联，不能用一个“已关闭”把这些不同结果混在一起。

先确定一条业务约束：仓库取得出库执行权之前允许直接取消；取得之后不再直接取消，需走拦截或售后流程。这不是所有电商平台的通用规则，而是本案例采用的取消边界。你的业务如果允许打包后撤销，需要另补“撤销出库申请”的条件与仓库确认，不能直接照搬箭头。

状态	明确含义	不能据此推断
待履约	支付已确认，仓库尚未取得出库执行权	仓库稍后一定有货
出库锁定	本次出库任务已取得执行权，直接取消入口关闭	包裹已经交给承运方
已发货	收到符合业务约定的发货确认	买家已经收到商品
已完成	满足本例确认收货的完成条件	售后权利一并结束
已取消	履约终止，不再取得新的出库执行权	退款已经到账

“出库锁定”值得单独成为状态，因为它改变了用户能否直接取消。相反，“客服查看过订单”只是一次记录，不必变成状态。判断是否新增状态，可以问：它是否改变后续允许的事件、处理责任或业务承诺？如果都没有，保留为属性或操作日志通常更清楚。

把每条箭头写成可核对的转换表

转换可以按“事件 [允许条件] / 动作”的方式标注。事件是发生了什么，例如“申请取消”；条件是这时能否执行，例如“订单仍待履约且请求人有权限”；动作是通过后要做什么，例如“记录取消原因”。不要把三者都缩成箭头旁的“取消”两个字。

编号与当前状态	事件与允许条件	目标与后续动作	未通过时
T1 待履约	申请取消；身份、订单归属及当前状态校验通过	已取消；保存原因，可靠地登记后续资金处理任务	保持当前状态；返回不可取消原因
T2 待履约	申请出库；执行方有权限，取得该订单本次出库执行权	出库锁定；记录出库任务号，之后才允许执行出库	不启动出库；读取最新状态再处理
T3 出库锁定	发货确认；订单号、出库任务号及确认来源一致	已发货；记录本次发货信息	不改成已发货；保留消息并核查归属
T4 已发货	订单本人或经授权客服确认收货，关联本订单本次发货记录；本例不设自动收货	已完成；保存确认者、发货记录与完成时间	保持已发货；返回未满足的条件

T1 与 T2 必须争用同一份权威状态。后端需要将“仍是待履约”的校验与目标状态提交作为不可分开的裁决处理，避免两个请求都读取到旧状态后分别成功。实现可采用合适的条件更新、锁或其他并发控制，但不能仅靠前端隐藏按钮。数据库的事务隔离与条件更新语义可参考 PostgreSQL 并发更新说明；具体方案要与实际数据库和仓库系统共同确认。

还要处理“状态已保存，后续任务没发出去”的情况。评审记录应写清资金处理、通知等任务如何可靠登记、重试及对账。把“已取消”改回“待履约”来补偿通知失败，会重新开放出库，改变业务含义，应避免这种修补。

用同一张订单走完两种竞争顺序

设订单 O-1042 当前为待履约、版本为 12。用户申请取消，仓库申请出库；两边都曾读到这个版本。不要用浏览器点击时间或两个系统的本地时间决定谁先成功，应看权威状态的提交结果。

1. 取消先提交：T1 将待履约改为已取消。随后到达的 T2 发现条件已不成立，不得启动出库。用户看到取消成功，仓库得到停止处理的结果。后续资金处理仍要单独查询。
2. 出库锁定先提交：T2 将待履约改为出库锁定。随后 T1 不再满足直接取消条件，系统应返回“订单已进入出库处理”的实际原因，并按业务提供拦截或售后入口，不能仍提示取消成功。

这里有一个容易漏掉的前提：仓库必须在成功取得执行权后才开始出库。如果仓库先交接包裹、随后才回写“出库锁定”，再完善的订单状态图也拦不住实际发货。评审要让仓库接口负责人确认这个动作顺序。

请求超时也不等于提交失败。若取消或出库申请已经提交、只是响应丢失，调用方应使用原请求标识查询处理结果，或按双方约定以同一标识重试并查重，不能换一个新标识再次发起业务。在结果确认前，页面不承诺取消成功，仓库也不能仅因请求已发出就开始出库。

出库锁定之后长期没有发货确认，也不能按超时直接恢复待履约。先核查包裹是否已交接、旧出库任务是否确实停止、迟到确认如何识别；确认能撤销执行权后，才能为解锁设计独立的转换。本例不画自动解锁箭头，避免把“尚未收到结果”误当成“没有执行”。

在 Boardmix 中把规则、图和疑问放在一起

从 UML 绘图入口进入工作区后，使用图形与连接线搭建状态图：将“待履约”放在左上，“已取消”放在它的下方；右侧从上到下排列“出库锁定、已发货、已完成”。连接 T1—T4 对应的箭头，箭头旁先写事件名称，较长的条件另放在转换表中，以编号对应。

画布下方安排两行评审记录：“取消先提交”和“出库锁定先提交”。每行写出首次提交结果、第二个请求的结果、用户提示及仓库动作。这样团队看到的不只是五个状态，还能检查同一个冲突在不同顺序下是否都合理。

不要用红色箭头把所有非法操作也画进主图。主图保留允许的转换，把“出库锁定后申请取消”“已取消后收到发货确认”等问题列在旁边的异常记录区，分别注明拒绝、重复处理或人工核查。颜色只辅助辨认，编号和文字才能准确对应规则。

如果不确定该画状态图还是活动图，可以先看对象生命周期与业务流程的区别。这次讨论的主角始终是同一张订单；客服、仓库、物流各自做了什么，可另用流程或交互图展开，避免把不同抽象层次塞进同一张图。

把评审结果变成验收用例

每条用例都要同时看接口结果与最终保存的数据。只检查页面上的状态文字，发现不了后台已取消但仓库仍启动出库的问题。下面的输入和预期可直接改成你们的测试数据。

用例	准备与触发	应核对的结果
正常履约	待履约，依次申请出库、确认发货、确认收货	依次进入出库锁定、已发货、已完成；任务号与订单号一致
取消先成功	同为待履约的取消/出库请求，让取消先提交	最终已取消；出库请求未取得执行权；无新增出库动作
出库先成功	相同初始条件，让出库锁定先提交	取消被拒绝；最终至少为出库锁定，不应变成已取消
重复请求	重复发送同一取消请求，或重复同一发货确认	按订单号、事件类型与原请求标识识别重复；不再次登记资金任务或重复推进状态
提交响应丢失	取消或出库申请已提交，调用方未收到响应	按原请求标识查回既有结果，不新增业务请求；出库执行前确认已取得执行权
非法跳转	待履约时直接发送确认收货	拒绝；状态不变，记录实际原因
结果不明	已出库锁定，发货响应丢失或超时	不直接解锁；按任务号查证，区分待确认与确定失败
无权操作	另一用户对 O-1042 申请取消	服务端拒绝；不能因订单处于待履约就放行

最后为每次尝试留足排查信息：订单号、事件或请求标识、执行者、处理前状态、期望版本、提交后状态、成功或拒绝原因、关联出库任务号。重复事件应关联已有处理结果；拒绝事件也要能追溯，不能只记录成功转换。

同一个请求标识如果携带了不同的订单、事件或关键参数，应当报冲突，不能直接沿用上一次成功结果。去重的目标是避免重复执行业务，而不是把不同请求误认成同一件事。

评审结束时，应能拿走一套互相对应的材料：状态图解释“能去哪”，转换表解释“何时能去”，用例解释“怎样证实规则被执行”。当业务增加拆单、部分发货或售后，再先划分对象与责任，逐项扩展规则，而不是把更多状态名称挤进原图。