大学校园外卖系统怎么选？从交接回执丢失检查恢复契约

在大学选择校园外卖系统，没有开发团队也要能判断交接是否可恢复。技术验收应让普通操作员经历“提交交接后回执丢失”：系统能查回原请求的逐项结果，已成功订单不重复交接，失败单有明确原因。下面给出该场景的完整状态及数据边界。

输入、身份与存储约束

请求包含campus_id、request_id及去重后的order_ids；operator_id取已认证会话，不能相信请求自填。服务端先验证当前校区权限，再按规范化订单列表计算body_hash。同一校区同一request_id只对应一份输入和已提交结果，跨校区不复用权限。

订单以校区和订单ID为主键，状态限定received、handed_over、cancelled；交接仅允许received到handed_over，已交接返回already_done，取消单返回cancelled，缺失单返回not_found。只有当前操作者有本校交接权限时才执行，不能因请求ID已存在而跳过认证。

持久化约束

CREATE TABLE handover_result (
 campus_id VARCHAR(64) NOT NULL,
 request_id VARCHAR(64) NOT NULL,
 operator_id VARCHAR(64) NOT NULL,
 body_hash CHAR(64) NOT NULL,
 status VARCHAR(16) NOT NULL CHECK(status IN ('committed','rejected')),
 result_json TEXT NOT NULL,
 PRIMARY KEY(campus_id,request_id)
);
-- 同一数据库事务内：锁定本校待交接订单，核验操作者与当前状态。
-- 将实际允许的逐项状态变更与 handover_result 一起提交。
-- 同键同摘要读取原result_json；同键不同摘要返回409，不再次变更。

完整状态转换与正常输入输出

请求初态为未记录；鉴权失败直接403且不写业务结果。鉴权通过，在事务内锁订单并计算每项结果；业务变更与committed回执同时提交。数据库失败则全部回滚，调用方视结果未知，用同一个request_id查询；查不到可沿原键恢复，不生成新键绕过。

示例输入本校A、请求R1、订单[11,12,13]，初态依次为received、cancelled及不存在。预期输出[{11:handed_over},{12:cancelled},{13:not_found}]，回执标committed。这里committed表示此次处理已持久化，不表示三单全成功。

同R1同列表再次请求返回原逐项结果，不再次改变11。若R1改传[11,14]返回409冲突，不处理14；如果换了无A校权限的人，即便知道R1也返回403。结果查询只返回该校授权字段，不能泄露其他校区的订单。

异常反例与并发边界

只在内存缓存R1，进程退出就失去防重依据；先写回执再改订单会出现假成功，先改单后单独写回执会留下重复风险。必须把两者放在同一事务，并固定锁顺序处理重叠订单，唯一键冲突后回滚再读取已提交回执。

已交接后的取消属于独立业务补偿，不允许重放R1覆盖当前订单。响应中区分原请求结果与当前状态。失败且完全回滚时可用原键恢复；已提交、待核对与明确业务拒绝分别记录。以上为设计输入输出，未实现整套服务，不声称测试通过。

回到采购：检查点应能被普通操作员观察

实际演示时要求操作员记录请求或批次引用，断网后查逐项结果，再对失败单走明确流程。微订第一方校园资料列有批量中转等能力；本文设计仅支撑交接恢复子问题，不是其内部实现。具体套餐、培训、权限与端到端可用性仍按实际版本演示。

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