数据接口管理：请求超时后，如何避免重复写入？

先把超时记为结果待确认

发送方没有及时收到响应，并不能据此认定接收方没有执行。以创建工单为例，请求可能停在网络途中，也可能已生成工单、只是返回链路中断。若把这两种情况都当成“创建失败”并立即再次提交，就可能出现两个业务结果。

建议联调时明确区分已确认成功、已确认未执行和结果待确认。每次写入保留可以用于查询的业务标识及必要的请求摘要；遇到不确定结果时，优先通过约定的状态查询或双方核对流程处理。这里的状态划分是项目设计建议，具体接口是否具备查询能力须事先确认。

核对幂等语义，不只看方法名称

RFC 9110第9.2.2节说明，幂等关注相同请求重复执行所产生的预期效果；对于非幂等方法，客户端不应在缺乏相应依据时自动重试。因此，创建类写入不能仅因为发生超时，就套用查询接口的恢复策略。

在项目设计中，可以与接收方约定稳定的业务操作标识，让同一次操作的重发能够被识别。还需要明确标识的作用范围、有效期、并发处理及结果保存方式。同一标识携带不同业务内容时，应产生明确的冲突处理，不能悄悄覆盖；一个新的业务操作则应使用新的标识。仅由发送方增加字段而接收方不执行去重，并不能解决重复写入。

参考：RFC 9110: HTTP Semantics。

把等待提示与是否可重试分开判断

RFC 6585定义了429状态，服务端可通过Retry-After提示等待时间；RFC 9110说明该字段可使用日期或延迟秒数。等待提示回答的是何时再发，不等于证明上一笔业务未执行，也不会自动让非幂等写入变得可安全重发。

建议把重试资格、等待安排和业务截止时间分开配置。先依据双方约定判断是否允许再次请求，再处理服务端等待提示，并设置明确的尝试上限及人工接管入口。还应检查应用、网关和调度任务是否各自重试，避免同一失败在多层放大；重试责任宜有一个清晰的协调位置。

参考：RFC 9110: HTTP Semantics；RFC 6585: Additional HTTP Status Codes。

用故障情形验证业务结果

联调不能只检查最终返回成功。建议在获准的测试环境中模拟响应丢失、并发重发与恢复后补发，并同时核对接收系统实际产生的业务对象。下表为项目测试建议，具体失败注入方式由双方确认。

若接收方只返回“已收到”，还需区分受理与业务完成。状态查询应能说明当前进度；无法确认时记录待核对，不把技术层收到请求直接计为业务成功。

为不能自动恢复的请求保留核对出口

建议异常记录只保留必要的业务标识、发送时间、响应状态、尝试次数及查询结果，并按实际数据性质控制内容范围。不要为了排查方便，把完整个人信息、访问令牌或所有业务报文写进通用日志。核对人员需要的是能关联两端结果的线索。

在恢复流程中，先查已有结果，再决定补发、人工确认或执行经过批准的补偿动作。特别是跨多个系统的操作，不能把重复调用或简单反向请求视为可靠回滚。联调结束时应交付可重试条件、停止条件和责任清单；连接能力与业务恢复能力需要分别验证，才能减少重复单据与遗漏处理。