企业系统之间做接口对接，主流协议有三类：RESTful接口用于同步请求响应，消息队列用于异步解耦，文件加报文用于大数据量和跨网络批量交换。选型看三个因素——实时性要求、数据量大小、双方系统是否在同一内网。对接流程通用做法是：先约定接口文档，再做联调，然后上线并配监控。协议选得合适，后续维护成本会低很多。

三类主流协议

RESTful接口

这是目前最通用的对接方式，通过HTTP协议传递JSON格式数据，调用方发一个请求，被调方同步返回结果。优点是简单、跨语言、跨网络都能用，外部合作方对接几乎都用它。缺点是同步等待，调用链长时容易累积延迟，且一次只适合传一条或一批数据，不适合传超大文件。在保定，企业官网与订单系统、小程序与后端之间的对接，绝大多数走的就是RESTful接口。

消息队列

调用方不直接等对方处理完，而是把消息投到队列里，由下游系统自己去消费。这种方式把两个系统解耦：下游挂了，消息先攒在队列里，恢复后继续处理，不会影响上游。适合库存扣减后通知仓储、支付成功后通知发货这类需要异步通知的场景。代价是多了一个中间件要运维，且消息顺序和重复消费要自己处理。

文件与批量报文

双方约定一个目录或SFTP，定时交换CSV、Excel或定长格式文件，适合每天对账、每日数据汇总这种大批量、不需要实时的场景。优点是对双方系统侵入小、跨网络也能传；缺点是有时间差，且字段校验要靠双方约定格式。在保定，企业与银行、税务、供应链平台之间的对接，很多至今仍用文件交换方式，因为这些外部机构提供的就是标准报文接口。

协议选型怎么定

实时性要求秒级、需要立刻拿到结果的，用RESTful同步接口；可以容忍几秒到几分钟延迟、希望双方解耦的，用消息队列；数据量大、按天批量交换的，用文件方式。还要考虑网络环境：两个系统在同一内网，性能敏感可以走更轻的内部调用方式；跨公网对接外部合作方，就老老实实走HTTPS加鉴权，不要图省事裸奔。

标准对接流程

第一步：约定接口文档

文档要写清楚：每个接口的地址、请求方法、入参字段名和类型、出参结构、错误码定义、鉴权方式。字段命名、时间格式、金额单位必须双方确认。这一步最容易被跳过，但后期出问题回头补文档，代价是前期写文档的十倍。在保定做对接项目时，成熟的团队会把接口文档做成在线可联调的形式，改一处双方都能看到最新版。

第二步：开发与联调

双方按文档各自开发，先在测试环境用模拟数据对通。联调时重点测三件事：正常请求能否返回正确结果；入参非法时能否返回明确错误；网络超时或对方不可用时调用方会不会卡死。涉及金额、库存的接口必须做幂等，保证重复请求不产生重复业务。

第三步：上线与监控

上线后为每个接口记录调用日志，监控成功率和响应时间，失败自动告警。关键链路要有补偿机制：消息没消费成功要能重投，文件没解析成功要能重传。定期核对双方数据是否一致，避免接口跑了半年才发现两边对不上账。

常见误区

误区一：所有对接都用同步接口，结果一个慢查询拖垮整条链路。耗时操作应改异步。误区二：鉴权只靠一个写死的密钥，泄露后无法控制。应支持密钥轮换和按接口授权。误区三：不做数据校验，对方传错格式直接导致本地报错。入参必须在入口处统一校验。把这些细节做好，接口对接就能长期稳定运行。

安全与限流

接口对外暴露就要考虑安全。除了身份校验，还要做访问频率限制，防止被恶意刷或被误调用打垮服务；涉及敏感数据的接口要记录调用日志，便于事后审计。跨公网对接时，报文里不要把密钥明文放在请求参数中，应放在请求头并定期轮换。在保定，企业对接外部合作方时常见的疏漏是图联调方便，把测试环境的接口地址直接带到生产，上线后才发现没加鉴权，这种低级错误靠上线前的安全检查清单可以挡住。

最后要强调文档的持续维护。接口在运行过程中会不断调整版本，旧版本不能一下子废掉，要给调用方留够切换时间。对外提供的接口应做版本管理，新旧版本并行一段时间，确认所有调用方都迁到新版本后再下线旧版本，避免一方升级、另一方还在按老格式调用导致对接中断。