同城跑腿系统联调时常见做法是支付一通就对外宣称上线。更稳的做法是把「下单与订单状态」和「收款回调」拆阶段验收前者不依赖真实通道后者用沙箱 profile避免支付未过却改订单写入口。结论订单状态推进应由领域事件驱动支付成功只是其中一种触发骑手端任务列表订阅同一 order_id 的状态流而不是各自轮询不一致的缓存。// 示意支付回调只发事件不直接改骑手任务表publicvoidonPaymentSuccess(PaymentEvente){orderService.markPaid(e.getOrderId());dispatchService.enqueueIfNeeded(e.getOrderId());}骑手端与后台宜共用 order_id 作为关联键禁止仅用骑手手机号匹配订单否则改派后易出现双任务。验收清单应包含支付 mock、派单、送达、导出四段。一、下单链路先于收款验收用户叫单、填写地址与备注、生成 order_id、进入待支付——这一段应在 mock 支付下跑通。后台与骑手端可先不派真骑手能看到待接单队列。若此阶段依赖真实收款才创建订单试跑成本与风险都偏高。帮买场景可在订单表增加 purchase_amount 字段与 delivery_fee 分列退款 API 需声明退哪一段。试跑时各下一单核对用户端展示与 export 列一致。二、骑手端同步模型骑手 App 拉取任务列表时宜带 last_sync_token 或版本号避免覆盖本地进行中的操作。送达动作应 idempotent重复提交不会生成双份完成记录。改派时旧 task_id 关闭、新 task_id 关联同一 order_id审计日志保留。SELECTorder_id,status,updated_atFROMordersWHEREorder_id?;-- 骑手 task 表通过 order_id 关联禁止仅用手机号模糊匹配长轮询与 WebSocket 二选一即可关键是版本号递增客户端收到旧版本包应丢弃。弱网重复点「送达」必须幂等避免完成时间被覆盖。三、支付回调边界回调验签、更新支付状态、触发派单——三步宜在同一事务或可靠消息中完成。回调失败重试时订单不得从已支付回退到待支付。沙箱与生产 merchant profile 分离配置中心可读环境标签防止试跑回调写入生产库。notify URL 白名单宜在支付验收前开通。dead letter 队列要告警否则财务以为未收款实为回调堆积。四、轨迹与状态解耦GPS 上报写入轨迹表不直接改订单 status。完成动作由骑手确认送达触发轨迹仅作纠纷参考。导出 CSV 以 status 与时间戳为准避免「有轨迹无完成时间」的财务缺口。轨迹表只作纠纷证据报表以 statusfinished 为准。导出宜含 rider_id、finished_at、order_type 列。五、与外卖共库时的字段订单表增加 business_line 枚举跑腿与外卖共用 user_id。导出增加类型列财务分 sheet。模块开关控制前台是否展示跑腿入口避免未部署业务被点击。business_lineerrand 与 food 共用 user 表列表 API 默认带 line 过滤。前台 module 开关关闭时不应返回 errand 路由。六、光合同城边界国内综合版支持跑腿扩展与私有化交付商务结算规则由客户确定系统侧不抽成客户平台订单。定制计价、第三方调度对接宜单列里程碑。定制调度算法、第三方运力对接宜单列 adapter 接口不污染核心状态机。七、小结拆验收降低联调风险先 golden order 走状态机再沙箱支付最后生产小额单三处留证。改派、取消、拒单各造一单检查 rider 任务与 order status 是否一致。上线前用固定 order_id 跑导出样本列名变更 bump 版本并留财务签字。弱网环境下重复点送达确认 idempotent 不会双计完成。取消进行中的单时骑手端任务应同步撤销避免幽灵任务占运力。上线后每周用 golden order_id 回归导出 diff。改配送费规则前抽进行中单与新单对照 snapshot。