校园外卖混合配送方案：分段交接如何避免状态成功而通知丢失

校园外卖混合配送可以组合常驻与临时运力、校外校内接力以及人工加自取。对同单分段接力，关键工程问题是：上一段交接已保存，通知没有发出，下一段会不会永远收不到任务？用订单段状态与事务事件一起落库，再允许事件重复投递，可以把故障限制在可查询、可恢复的范围。

模型：业务状态与发送状态各管一件事

route_order以tenant_id、order_id为主键，保存campus_id、route_version、current_segment及version；route_segment以tenant_id、order_id、segment_index为组合主键，保存actor_id、state和receipt_id。段序号连续，state仅取ready、carrying、handoff_pending、done，只有最后段done且前段都done时整单才completed。

outbox以event_id唯一，含tenant_id、order_id、segment_index、event_type、payload、payload_digest、send_state、created_at；consumer_inbox以consumer_id、event_id唯一。本文为设计，尚无运行测试记录。摘要不是鉴权，租户和操作者来自认证上下文。

事务核心顺序

BEGIN;
SELECT version FROM route_order WHERE tenant_id=:tenant AND order_id=:order FOR UPDATE;
-- 认证范围、原version、前后段状态及接收凭据逐项校验
-- 任一不满足：ROLLBACK，返回具体冲突
UPDATE route_segment SET state=:next WHERE tenant_id=:tenant AND order_id=:order AND segment_index=:part;
-- 接收时在同事务更新前后两段，不拆成两次独立提交
UPDATE route_order SET version=version+1 WHERE tenant_id=:tenant AND order_id=:order;
INSERT INTO outbox(event_id,tenant_id,order_id,segment_index,event_type,payload,payload_digest,send_state,created_at)
VALUES(:event,:tenant,:order,:part,:type,:payload,:digest,'pending',CURRENT_TIMESTAMP);
COMMIT;

逐步输入输出与异常反例

构造输入C1/O17/v1，两段分别由A和B负责。A提交交接后，段0=handoff_pending，段1=ready，outbox=E1/pending；发送进程此时宕机，业务仍未整单完成。恢复扫描E1，B收到任务并接收，输出段0=done、段1=carrying；B最终交付后两段done，整单completed。以上是预期结果，不是实跑日志。

反例：先更新段为handoff_pending，提交后单独发送通知，恰好进程退出，业务状态已变但消息永久丢失。另一反例是消息发送后未标sent就退出，恢复重发导致B重复接单；消费者按event_id建立唯一收件记录，业务修改与收件记录在本地同事务提交。同ID不同内容应冲突，不因唯一键存在一律称成功。

outbox只解决本地业务记录与待发事件一致性，不保证外部短信送达、消息顺序或实物交接。可按order/version检测乱序并查询权威当前状态，无法按序处理时进入待办；不能从旧事件推断最新持有人。

回到混合配送验收

运力分组未必需要同单接力；只有发生交接的路线才需要相应段模型。微订校园产品页列有多校区独立后台和批量中转，为业务讨论提供第一方背景，本文不声明为微订实际数据库或消息架构。采购演示应核正常交接、发送中断、重复事件与未确认接收，设备、费用与学校准入另验。

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