一、先分清“对接”到底是哪一种
1. 单向查询
系统 A 只从系统 B 查询资料，例如查询客户、商品、库存或订单状态，不修改对方数据。
这类接口风险相对较低，但仍要处理账号权限、查询频率、分页、超时、缓存和接口限流。
2. 单向写入
系统 A 向系统 B 创建或修改数据，例如商城订单同步到 ERP、CRM 客户同步到客服系统。
一旦涉及写入，就必须考虑重复提交、部分成功、字段校验、错误返回和撤销规则。一次网络抖动不能让 ERP 多出两张相同订单。
3. 双向同步
两个系统都可能修改同一类数据，例如 CRM 和 ERP 都能修改客户资料，商城和仓储系统都能改变订单状态。
双向同步最难的不是“互相调用”，而是确定谁是主数据源、发生冲突听谁的、修改历史如何追溯。没有主从规则，很容易出现两个系统反复覆盖。
4. 业务流程联动
对接不只是传字段，而是让一个系统的业务动作触发另一个系统的流程。例如合同审批通过后创建项目、生成应收计划、通知财务并同步电子签章状态。
这种项目需要理解完整业务规则，通常已接近流程系统开发，不能只按接口个数估价。
5. 文件或数据库交换
部分老系统没有标准 API，只能通过 Excel、CSV、SFTP、消息队列或数据库视图交换数据。
这种方式并不一定不可靠，但需要额外处理文件版本、编码、重复导入、数据锁、权限和定时任务。直接读写对方生产数据库风险尤其高，应有清晰授权和隔离方案。
二、接口数量为什么不能直接等于工作量
供应商常说“只有五个接口”，但一个接口可能只是读取字典，也可能包含几十个状态和多系统联动。
评估工作量至少要看：
- 一个接口包含多少字段和业务校验
- 是否涉及主子表、附件和图片
- 是否需要新增、修改、删除和撤销
- 是否要求实时，还是允许定时同步
- 是否需要处理历史数据
- 一次业务动作会调用几个系统
- 失败后是否允许人工补录
- 是否涉及支付、资金、发票或个人信息
- 对方接口文档和测试环境是否完整
所以，合理报价不会只写“10 个接口 × 单价”，而会把每条业务链路和异常场景拆开。
三、系统对接真正花钱的六个部分
1. 业务口径确认
两个系统里都叫“客户”，含义可能不同。CRM 的客户可能包括尚未成交的线索，ERP 的客户可能只包括已建立结算关系的主体。
类似差异还包括：
- 订单创建、支付、出库和完成分别代表什么
- 可用库存是否扣除了锁定量
- 含税金额和未税金额如何换算
- 退款、退货、作废和冲销如何区分
- 员工、部门、门店和组织编码是否一致
不先统一口径，接口即使技术上成功，业务数据仍可能错误。
2. 身份认证和权限
接口需要证明“谁在调用”。常见方式包括 API Key、签名、OAuth、证书、IP 白名单和专线。
生产环境还要考虑密钥存放、轮换、过期、最小权限和泄露后的撤销机制。把账号密码直接写在代码或聊天记录里，会给后续运维留下严重隐患。
3. 字段映射和数据转换
同一个业务字段在两个系统中可能名称、类型、单位和取值不同。例如：
- 性别一个系统用 0/1，另一个用 male/female
- 金额一个用元，另一个用分
- 时间一个使用北京时间，另一个使用 UTC
- 商品一个按 SKU，另一个只按产品编码
- 地址一个是完整文本，另一个拆成省市区
这些转换必须有映射表、默认值和异常规则，不能散落在代码中靠开发人员记忆。
4. 幂等、重试和异常补偿
网络请求超时，不代表对方没有处理。调用方如果直接重试，可能重复创建订单、付款单或出库单。
因此写入接口通常需要业务唯一键和幂等规则。失败后也不能无限重试，要区分：
- 临时网络错误，可以自动重试
- 参数错误，需要修正数据
- 权限错误，需要更新配置
- 对方业务拒绝，需要人工处理
- 部分成功，需要补偿或回滚
这些“看不见的代码”往往比正常路径更耗时，却决定系统上线后是否可靠。
5. 联调、测试和验收
接口开发完成后，需要双方系统共同联调。常见阻塞包括测试账号未开通、测试数据不足、文档与实际返回不一致、对方窗口期有限。
测试不能只覆盖一条成功数据，还要覆盖空值、重复请求、超时、批量数据、状态回退、权限不足和对方停机。
6. 监控、日志和运营工具
对接上线后，企业需要知道今天同步了多少条、失败多少条、哪一条卡住、是否可以重试。
如果没有可查询日志、告警和人工补偿入口，任何异常都要找开发人员翻服务器日志，维护成本会持续升高。
四、系统对接的参考费用怎么分级
| 复杂度 | 典型特征 | 参考预算 |
|---|---|---|
| 简单 | 单向查询或写入、字段少、文档完整、无复杂状态 | 5000～15000 元 |
| 中等 | 多接口、主子表、状态同步、重试、基础后台 | 15000～50000 元 |
| 复杂 | 双向同步、多系统、历史数据、资金或库存、补偿流程 | 50000～150000 元以上 |
| 平台级 | 多租户、开放平台、统一网关、高安全与高可用 | 需专项评估 |
参考区间不是按“一个接口多少钱”计算，而是按一条完整业务链路能否稳定运行计算。
同样是订单同步，只有订单头和金额，与包含商品明细、优惠分摊、库存锁定、支付、发货、退款和发票的链路，成本可能相差数倍。
五、最容易被漏报的成本
对方系统配合费用
部分 SaaS、ERP 或硬件厂商会收取接口开通、技术支持、测试环境或流量费用。这些费用不是开发团队决定的，应在立项前确认。
历史数据处理
“上线后同步新数据”和“把过去三年全部数据迁移并对账”是两项工作。历史数据往往存在空值、重复和旧编码，需要单独评估。
网络和安全环境
专线、VPN、固定 IP、证书、堡垒机、等保环境和跨境网络，都可能增加部署与协调成本。
数据主档治理
如果两个系统的客户、商品、组织和仓库编码长期不一致，接口项目可能先变成一次主数据治理。否则任何同步都会产生大量人工异常。
上线窗口和回滚
必须在夜间、月底或业务低峰切换时，需要准备演练、值守和回滚方案。上线不是按一下发布按钮。
六、一条可靠的对接链路应该怎样设计
以“商城订单同步 ERP”为例，完整链路通常包括：
- 商城生成业务唯一订单号
- 校验客户、商品、仓库和金额
- 调用 ERP 创建订单
- 记录请求摘要和返回结果
- ERP 返回自身单号并建立映射
- 超时后先查询是否已创建，再决定是否重试
- 失败数据进入异常队列
- 运营人员查看原因并修正或重新提交
- 每日核对两边订单数量和金额
- 关键异常触发告警
如果报价只覆盖前三步，演示可能很快成功，生产运行后却会不断出现重复单、漏单和对不上账。
七、项目应该按什么顺序推进
第一步：接口盘点
列出系统、负责人、接口文档、账号、环境、数据对象和调用限制。确认哪些条件已经具备，哪些需要外部厂商配合。
第二步：业务流程和主数据确认
用流程图说明数据何时产生、谁修改、谁是权威来源、失败如何处理。为客户、商品、组织等建立编码映射。
第三步：接口契约
确认字段、类型、必填、枚举、示例、错误码、幂等键和版本。接口文档应能被双方共同评审。
第四步：先做一条闭环
不要同时铺开所有接口。先选择一条价值高、边界清楚的链路，完整实现成功、失败、重试、日志和对账。
第五步：联调和异常测试
准备正常、边界和错误数据，记录每种结果。双方确定问题归属、修复方式和回归测试。
第六步：灰度上线
先处理少量真实数据，核对无误后逐步扩大。高风险链路需要保留人工审批或双轨运行。
八、验收清单应该写进合同
建议至少确认：
- 接口清单与版本
- 字段映射表
- 成功和失败状态定义
- 幂等与重复请求处理
- 超时、重试与补偿规则
- 日志保留期限
- 异常查询和人工重试入口
- 监控与告警方式
- 性能和调用频率
- 历史数据范围
- 数据对账规则
- 密钥与权限交付
- 测试用例和验收结果
- 上线、回滚和质保责任
接口能返回 200，不等于业务对接验收通过。最终应以数据一致、流程可追踪、异常可处理为标准。
九、老板怎样识别不完整的低价报价
出现以下情况时，应继续追问：
- 只按接口个数报价，不问业务状态
- 不关心谁是主数据源
- 没有测试环境也直接承诺周期
- 没有幂等、重试和对账设计
- 把所有异常都归为“人工处理”
- 不交付接口文档和映射表
- 不说明第三方厂商配合费用
- 上线后没有日志和查询入口
低价方案不一定不能用，但企业必须知道它省掉了什么。如果省掉的是后台、告警或自动补偿，也许可以接受；如果省掉的是数据一致性和安全，就可能把成本转移到上线以后。
十、常见问题
对方有 API 文档，为什么还要评估？
文档只能说明技术入口，不能替代业务口径、权限、异常、历史数据和联调条件。还要验证文档是否与实际版本一致。
能不能直接连接对方数据库？
技术上可能可以，但风险通常高于标准 API。数据库结构可能变化，也容易绕过业务校验。若必须使用，应限制为只读视图或经过授权的交换库，并做好审计。
使用消息队列是不是一定更可靠？
消息队列能改善解耦和削峰，但不能自动解决业务重复、顺序、数据冲突和消费失败。是否需要应根据实时性和规模决定。
接口项目上线后为什么还需要维护？
两个系统都会升级，字段、权限、证书和业务规则也会变化。接口是长期连接，不是一次性交付后永远不变。
只有几个简单接口，是否值得做监控？
值得。哪怕只有一个订单接口，只要它影响收入、库存或客户体验，就需要知道失败发生在哪里。
