API接口对接常被理解为“拿到文档、发出请求、收到响应”。实际项目里，请求成功只代表一次调用走通；数据在两个系统中怎样对应、失败后由谁处理，还要靠联调确认。开始编码前，先把这次对接要完成的业务动作说清：是查询已有数据，还是向对方创建一条记录？两种动作遇到超时，处理方式并不相同。

文档已经拿到，业务动作还没对齐

接口文档会写地址、字段和返回格式，但“下单成功”在双方系统中的含义未必一致。本系统显示提交成功，可能只表示请求已被对方接收；对方是否生成订单，仍取决于其处理结果。对接双方应确认成功响应对应的处理阶段，并确定用哪个业务编号查询后续状态。

字段也要按实际业务核对。订单金额由哪一方计算、取消订单用什么状态表示，若只凭字段名称猜测，测试数据可能正常，正式数据却出现差异。接口负责人可以把有争议的字段连同一条脱敏请求样例发给对方确认，留下更新后的约定。文档版本发生变化时，联调双方使用同一版，避免各自按不同规则排查。

创建订单超时后，能不能直接重试

假设一个商城要通过API向履约系统创建订单。商城发出请求后等待超时，页面没有拿到结果，运营又在履约系统里看到了相同订单。此时无法仅凭超时判断创建失败：请求可能已经到达，响应却没有返回。若商城自动重发一次，履约系统可能收到两次创建请求。

处理这类情况，先核对请求日志中的业务订单号、发送时间和返回记录，再请对方按业务订单号查询接收情况。两边记录对不上时，保留原请求标识和错误信息，不急着用新订单号补发。联调要谈清楚一项具体约定：相同业务订单号重复提交时，对方返回原订单结果，还是再次创建。若接口支持幂等键，同一笔业务在重试时沿用同一个键；若暂不支持，就要明确超时后的查询入口及人工处理方式。

这个情境仍有现实取舍。等待查询会延迟订单流转，直接重试又可能产生重复单。若对方暂时无法提供查询接口，双方可先限制自动重试，并约定异常订单由谁核对、如何回填结果。后续联调就沿用这条处理线，检查超时请求最终落在哪个状态，而不是只看下一次调用有没有返回成功。

联调通过后，正式环境还要核对什么

测试环境能调用，不代表正式环境已经具备相同条件。上线前核对正式地址、鉴权信息和访问权限，确认敏感凭证没有写进公开日志。测试数据与正式数据的字段长度、可选值也可能不同，联调时遇到的异常响应应保留样例，供上线后定位。

发布时给关键调用保留可追踪的请求标识，让双方能对同一笔业务查日志。若新接口影响原有下单流程，还需写清异常时暂停调用或回退的操作，以及由谁执行。上线后的第一批请求，核对本系统发送记录与对方接收记录；发现差异，就沿着业务订单号和请求标识定位，不用反复提交试探结果。