两个系统做接口对接，选好通信方式只是开始，真正决定对接稳不稳的，是鉴权、超时、幂等这些容易被忽视的工程细节。很多对接跑通测试就上线了，结果正式环境频繁掉单、被刷、数据错乱，问题往往就出在这些细节上。本文把接口对接协议里最关键的几个工程点讲清楚，帮你把对接做得又稳又安全。

鉴权：先确认"你是谁"

身份凭证怎么约定

接口不能谁都能调。两个系统对接时，要约定一套身份凭证，比如一串密钥或令牌，每次请求都带上，接收方校验通过才处理。这样能防止有人伪造请求、偷偷拉数据。北票市涉及订单、资金的接口，尤其要做严格鉴权，密钥还要定期更换，不能写死在代码里，否则一旦泄露就追悔莫及。

传输为什么必须加密

光有凭证还不够，传输过程也要加密，别用明文。否则凭证和数据在网络上等于裸奔，中间经过的节点都能看到。这是对接的基本安全底线，省下这一步，等于把大门敞开。尤其是跨公网的对接，加密不是可选项，是必须项。

超时：别让请求无限等下去

为什么要设超时

如果对方系统突然卡住，你的请求一直等不到响应，整个流程就会被拖死。每个接口都要设一个合理的超时时间，比如几秒内没响应就判定失败。超时后触发重试或告警，而不是让用户盯着转圈。超时时间要按接口实际响应速度来定，设太短会误杀正常请求，设太长又失去意义。

超时和重试要配对设计

超时重试是对的，但重试前要想清楚：对方到底处理没有？这就引出下一个关键——幂等性。没有幂等设计的重试，往往好心办坏事。所以重试策略不能单独定，必须和接口的幂等能力放在一起考虑。

幂等性：重复调用不会出乱子

哪些接口必须做幂等

所谓幂等，就是同一个接口调用一次和调用多次，结果一样。读数据的查询接口天然幂等，怎么查都不影响数据；真正要小心的是会改动数据的写接口。北票市凡是涉及写操作的对接——下单、支付、改库存——都必须做幂等，这类接口一旦忘了做，迟早会在某次网络抖动时出重复事故。

唯一请求标识怎么用

做幂等最常见的办法，是让调用方给每笔写请求带一个唯一标识，接收方收到后先查这个标识：没见过就处理，见过了就直接返回已成功、不再重复执行。这样哪怕网络抖动重发十次，结果也只落地一笔。支付接口靠这招，就能避免客户被扣两次钱。

错误信息：让对方知道错在哪

错误码要分哪几类

对接出问题时，别只返回一个笼统的"失败"。要约定好错误码和说明，至少区分三类：参数错了、权限不够、对方系统内部故障。接收方看到明确的错误码，才能决定是自动重试还是人工介入。北票市错误码表双方提前对齐，对接出问题时十分钟就能定位，而不是互相猜。

错误信息里还要带上足够的排查线索，比如请求编号、出错时间。这样出问题时，一方拿着请求编号去查日志，另一方顺着同一编号也能对上，不用两边各说各话、半天对不上同一件事。对接联调时把这几条都跑顺，正式环境才不会在这些细节上翻车。

把这些细节写进对接文档

联调要覆盖哪几种场景

鉴权方式、超时阈值、幂等规则、错误码表，都要在对接文档里写死，双方照做。口头约定的细节，迟早成为事故隐患。北票市一份写清楚工程细节的对接文档，能让两个团队在真正联调时少走很多弯路，也让后期接手的人看得明白。

联调时别只测正常流程。要用测试数据把正常、超时、重复、异常几种情况都跑一遍，确认超时会重试、重复会被拦截、异常有报警。这些场景在测试时暴露，成本很低；等到真实业务里才暴露，代价就大了。

企业系统接口对接协议，表面是选哪种通信方式，里子是鉴权、超时、幂等、错误处理这些工程细节。这些做扎实了，对接才能在正式环境长期稳跑，而不是测试一过就翻车。