接口对接的难点很少在"调不通"，而在"偶尔出错""对方说收到了我这边显示失败"这类问题。下面五处是实际项目里出错最集中的地方。
五个高频问题
| 问题 | 典型症状 | 标准处置 |
|---|---|---|
| 编码不一致 | 中文变问号或乱码，金额里的全角字符导致解析失败 | 统一 UTF-8；出入参都在协议里写明字符集；对入参做全角转半角 |
| 时间与时区 | "今天"的数据差 8 小时，跨天统计总是错一笔 | 传输统一用 UTC 或带时区的时间戳；只在展示层做本地化 |
| 签名与幂等 | 网络抖动后重发，对方生成两条订单 | 每次请求带唯一请求号；服务端按请求号去重；重复请求返回首次结果 |
| 限流与重试 | 高峰期大面积失败，重试又把对方打挂 | 退避重试 + 上限次数；失败的请求进队列而不是死循环 |
| 回调验签 | 有人伪造回调，把订单改成"已支付" | 回调必须验签并校验金额；回调处理要幂等；处理成功才返回成功 |
重试要带退避，不能死循环
下面这段逻辑是所有对接里最该有、却经常被漏掉的一段。它的作用是：失败时别立刻重来，而是把压力摊开。
第 1 次失败 → 等 2 秒
第 2 次失败 → 等 4 秒
第 3 次失败 → 等 8 秒
第 4 次失败 → 写入待处理队列，人工介入
（最多 3 次自动重试，超过就停下，不要无限重试）对接前必须确认的六件事
- 接口文档的版本与更新时间
- 测试环境的地址与账号什么时候给
- 对方是否有并发或调用频率限制
- 错误码清单，以及哪些错误码可重试
- 回调地址的要求（白名单、证书、超时）
- 对账机制：每天怎么核对双方数据是否一致
一定要做对账
接口对接的最终保障不是"代码写得好"，而是每天自动对一次账。把双方当天的记录拉出来比对，有差异就报警。这样最坏情况也只是"今天差一笔"，而不是"三个月后才发现差了很多笔"。
提醒：对接外部系统的工期，不要按"对方说 3 天给接口"来排。这类依赖往往不在你控制范围内，计划里至少留一周缓冲。