对接第三方，正常流程通常两天就能跑通，剩下的时间几乎都花在异常上。判断一个对接是否真正完成，不看首页能不能用，而看凌晨三点第三方超时的时候，你的系统会不会重复下单、会不会把钱算错。
一、先把异常分成三类
异常处理之所以难，是因为多数人把它当成一件事。实际上三类异常的处置方式完全不同，混在一起写代码，必然出错。
- 网络类：超时、连接被拒、DNS 失败——可以重试
- 业务类：参数错误、余额不足、状态不允许——不能重试，要修正后重发
- 状态未知：请求已发出，但没有收到回执——先查单，不要盲目重试
状态未知才是最危险的那类
它最容易被当成失败重试，结果就是重复下单、重复扣款。所以凡是写操作，都要有一个"按业务单号反查状态"的接口，这是对账能力的前提。
二、重试要有规矩
重试不是循环调用，而是一套有边界的策略。
- 指数退避：1 秒、2 秒、4 秒、8 秒，避免把对方打挂
- 设最大次数与总时长上限，超过就转人工或进补偿队列
- 只对幂等接口或带幂等键的请求重试
- 每次重试记录完整上下文：请求号、参数摘要、第几次、结果
三、幂等：一次请求只能有一次效果
| 场景 | 风险 | 做法 |
|---|---|---|
| 支付与扣款 | 重复扣款 | 用订单号做幂等键 |
| 提交订单 | 重复下单 | 前端防重 + 服务端幂等表 |
| 回调通知 | 重复处理业务 | 按通知流水号去重 |
| 库存扣减 | 超卖 | 单号唯一约束 + 事务 |
如果第三方本身就提供幂等参数，优先使用对方的机制；没有的话，在自己这边落一张幂等登记表，键就是业务唯一号，插入成功才继续处理。
四、超时、限流与降级
- 超时时间要小于业务能接受的最长等待，不要用默认值
- 对方有限流就按限流设计并发，别靠"重试碰运气"
- 非核心链路可降级：查不到实时数据就展示上一次结果，并标注时间
- 给运维留开关：出问题时能一键停掉某类调用，而不是改代码重发版
五、对账：最后一道保险
再严谨的实时处理也会有偏差，所以需要日终对账兜底。对账不需要复杂，关键是"差异有分类、处理有归属"。
- 按业务日拉取双方流水，先比总数与总金额，再逐笔比
- 差异分三类：我方多、对方多、金额不一致，各自对应处理路径
- 自动处理能覆盖的部分，剩下的进人工队列并限期处理
- 对账结果留档，作为后续争议的依据
最后附一份对接自查：超时值定过吗？写操作有幂等键吗？状态未知会查单吗？重试有上限吗？对账自动跑吗？告警到人吗？六项都答得上来，这个对接才算交付完成。
#接口对接#幂等设计#对账#系统集成
