接口失败重试、补偿与对账

接口失败时为什么不能直接再发一次？

先区分请求没有发出、对方明确拒绝、对方已经处理但回执丢失，以及当前无法判断的情况。超时通常只能说明调用方没有及时拿到结果，不能据此推断业务没有发生。订单下发、支付退款或库存扣减若盲目重发，可能重复执行一个本来已经完成的动作。

重试决策应依据业务编号与查询结果，而不是只看异常名称。若接口支持查结果，先用原操作编号查证；若对方只提供异步通知，需要说明等待期间的业务状态和处理岗位。没有任何查证机制时，应将其列为集成风险，通过额外适配或人工核验解决，不能用“会自动重试”掩盖未知结果。

正常读取请求与改变业务状态的请求也应区别处理。读取失败可能适合稍后再次读取，但写入操作需要考虑重复效果、授权和状态条件。团队应为每个场景写出可重试、不可重试和需要提供的类别，让运行人员能按相同规则判断，而不是临场尝试。

操作编号和订单编号是什么关系？

一张订单可能有付款、下发、取消和退款等多种动作。只用订单编号不能区分不同业务动作；随意换编号又会失去原操作的查证依据。设计时应说明操作类型、所属系统、业务范围和修订之间的关系，并约定哪些字段变化仍属于同一操作，哪些变化必须成为新的经批准动作。

幂等性需要覆盖业务效果。同一个操作重复到达时，应返回可解释的既有结果或当前状态，而不是再创建一个外部订单。只在网关短时缓存请求并不一定覆盖迟到重试、进程重启和长期回调；验收应检查完整业务链，并确认记录保留与查询方式满足实际需求。

编号还要跨商城或组织保持统一范围。不同商城存在相同本地订单号时，外部系统不能只按字符串去重。双方应把范围字段纳入查找与权限检查，确保某个账号无法查询或重放另一个范围的操作。日志中应保留关联编号，避免收集密钥、支付凭据或完整个人资料。

哪些错误可以重试，哪些需要改数据？

临时网络故障和明确的限流可以讨论延后重试，但应遵守对方接口约定；无效物料、状态不允许或权限缺失通常需要先处理原因。重复发送同一份错误资料会增加积压，无法提高成功率。失败分类应包含业务原因、可采取动作和终止条件，而不只是HTTP状态。

重试需要上限和运行控制。具体次数、间隔、最长等待及时间窗口应根据客户接口、交易风险与运行约束确认，运行人员应能暂停某类操作或某个系统的重试，查看影响范围，再在原因消除后恢复。暂停不应删除待处理任务或改变原业务编号。

对于付款或退款等高影响动作，重试时还要重新核对当前业务状态。例如原退款已经撤销或订单归属发生变化，不能继续执行之前的任务。重放权限应与日常查询权限分开，必要时由业务岗位批准，避免接口恢复过程产生新的资金问题。

补偿是回滚还是另一个业务动作？

跨系统已经完成的动作未必能用数据库回滚消除。仓库已经出库、渠道已经扣款或对方已经生成财务记录，都需要对应业务处理。补偿可能是撤销申请、退款申请、恢复额度或对账工单，其前提和结果应由相应系统确认，而不是在商城侧简单改回旧状态。

每个补偿动作应关联原动作，保存原因、批准人、输入版本和处理结果。部分补偿失败时，也要能继续查证当前状态，不能通过新的编号反复执行。对外部不可撤销动作，应明确转入人工处置或售后流程，避免在报告中使用“已回滚”这种无法说明业务结果的笼统表述。

补偿不宜承担所有错误修复。字段格式错误适合修订后重新提交；已经产生业务影响的错误，则需要判断怎样纠正业务。工程清单应区分技术重放、资料更正和业务补救，并给每种动作明确的权限与复核方式。

怎样证明异常恢复链路可以工作？

下表是一组验收设计记录。实际执行时应补充双方接口版本、隔离环境和脱敏业务样本；不会自动证明源码中已有通用补偿系统。

注入或模拟的情况	恢复前应确认什么	允许的动作	需要保留的结果
发送前连接失败	对方是否可能接收到请求	按契约重试原操作	原编号、尝试记录与最终效果
对方处理后回执丢失	对方查询是否已有业务结果	查结果后更新本地状态	外部对象与本地状态对应
对方明确拒绝资料	哪个字段及版本违反约定	修订资料，经确认后重提	拒绝原因、修订版本、业务批准
回调重复且顺序交换	状态和事件版本是否已应用	去重或隔离，不盲目覆盖	当前状态与原通知引用
自动恢复到达边界	未处理集合及影响业务是什么	暂停、升级岗位、人工决策	工单、责任人、后续验证

测试时同时观察业务对象和任务记录。任务标记成功但外部订单重复，不能算通过；外部动作完成但本地永远未知，也不能算闭环。应从消费者、客服或财务实际会查的入口核对结果，确保技术恢复不会留下无法解释的业务状态。

对账能发现哪些重试机制漏掉的问题？

任务系统只能处理自己已经看见的记录。若某个业务事件根本没有生成任务，重试队列中不会出现它。因此还需从权威业务集合出发，对比哪些对象应该发生外部动作、哪些已经有结果、哪些仍存在差异。对账和重试承担不同职责，不应互相替代。

先确定截止时间、组织范围、业务状态和金额口径，再按业务编号列出缺失、多出和属性不同的对象。总数相等可能掩盖错配，金额总额相等也可能来自多笔相反差异。差异应能回到原记录与事件，说明它属于未发出、未接收、未处理、映射不一致或业务例外。

修复前保存差异快照与待执行动作，避免直接使用当前查询结果批量修改。修复过程中业务仍可能推进，应在执行前再次核对状态。结束后使用相同口径复验，并检查该修复是否影响消费者展示、库存或财务记录。这样才能区分“任务队列清空”和“业务账目可解释”。

项目交接时必须留下哪些运行资料？

需要提供失败类别说明、原编号查询方法、暂停与恢复条件、可重放岗位、人工升级路径和对账报告读法。对接账号更换、外部接口升级或数据范围调整后，这些资料也应同步修订。没有实际执行证据的自动恢复能力，不能写成已验收的服务承诺。

回到系统集成专题规划整体范围，用ERP与WMS对接需求模板填写异常契约，通过系统集成服务沟通补偿与对账工程。具体商城接口依据见API契约说明，外部动作仍须按客户接口实现和验收。