校园中转系统接入是否稳定？用超时后的订单状态转换验收

判断校园外卖中转系统接入是否稳定，除了检查重复订单，还要确认“请求发出但没有收到回执”如何恢复。下面将接入事实与调用端观察拆开，给出状态转换、输入输出和反例，供采购演示与接口联调核对。

同一笔订单，服务端事实和客户端观察分开

服务端按tenant、source、merchant、external_id标识原单，保存payload_digest、receipt_id和accepted_at。唯一键范围由授权接口约定，tenant从认证上下文取得。调用端另存attempt_id、原单键、请求摘要和observation；attempt_id用于追踪这次网络尝试，不用于创造第二笔订单。

服务端结果为ABSENT、ACCEPTED或内容冲突；客户端观察为NEW、SENT、ACKED、UNKNOWN、RECONCILED。UNKNOWN描述调用端没有可靠回执，不能据此把服务端事实改成ABSENT。

逐步输入输出

输入C1/S/M1/O17、楼栋A、2500分，调用端记录attempt=R1后发出。服务端保存receipt=K1，网络恰在返回前断开：服务端是ACCEPTED，调用端是UNKNOWN。按同一原单查询得到K1及同摘要后，调用端转RECONCILED；有效订单仍是一条。

异常反例：超时后生成O18重发，服务端看见两个不同原单，无法知道它们其实来自同一次业务。另一反例是查询接口出错就按未找到处理；这会将查询故障升级成重复创建。因此UNKNOWN只允许查询及人工核对，确知未保存才按原键恢复。

验收结果怎样服务校园履约

把网络尝试、中转任务和实物餐品分别计数。原单只有一笔时，重试可以有多次，但不能让分拣清单多出一袋。查询原回执后再查看当前任务状态，历史接入成功不能自动推出当前尚未取消。

微订校园产品页作为第一方资料列有录码收单和批量中转。可以用这些业务入口安排上述用例；本文状态模型是通用设计，没有声明为微订内部实现或产品实测。未覆盖跨库任务一致性、身份鉴权实现、支付、性能与所有来源接口。

作者：微订（上海逊柯计算机科技有限公司）。