这里需要分开三件事：谁先受理和推进，问题由什么原因造成，整改及额外工作怎样安排。牵头排查的一方，不一定就是最终承担全部整改或费用的一方。 联调的重点，是验证两个系统能否按同一套规则完成业务交换。双方各自运行正常，只能说明局部情况，不能代替整条链路的验证。
把同一笔调用的两端证据放在一起
以一个假设的采购入库系统对接ERP项目为例：新系统显示“同步失败”，ERP团队却表示接口服务一直正常。
此时不能只交换一张错误截图，而应选定同一笔入库业务，关联业务编号、请求编号、发生时间和双方处理记录。
沿着这笔调用，可以依次核对请求是否真正发出、对方是否收到、身份与权限是否通过、字段和业务规则是否满足、数据是否写入，以及处理结果是否正确返回。
失败可能发生在发送前，也可能是对方已经完成写入，但返回结果没有被调用方收到。因此，“新系统显示失败”和“ERP里没有生成记录”不能直接画等号。
排查前还应核对双方使用的接口版本、测试地址、账号权限、网络访问规则和样例数据，避免一方查看测试环境，另一方查询正式环境。
日志和请求内容应保留必要关联信息，并对敏感数据、令牌和密钥进行保护。能够把同一笔业务在两端串起来，才更容易判断失败停在哪一步。
联调责任要分到具体动作，企业也有确认工作
负责新系统的团队，应核对自身请求构造、字段映射、接口调用、返回处理和已约定的异常机制，并提供相应记录。
既有系统或第三方平台的负责团队，则需要说明接口规则、账号权限、调用限制和处理状态，在其服务范围内协助查询接收与执行情况。
企业业务负责人也不能完全缺席。数量单位、仓库编码、客户归属、单据状态等口径，可能需要业务人员决定，不能由两个技术团队分别猜测。
例如，新系统按“箱”提交数量，而ERP按“件”处理，究竟在哪里转换，应由双方依据已确认规则落实。数据由哪个系统维护、冲突时采用哪一方结果，也应有明确主责。
项目中还需要一个联调协调入口，记录当前问题、下一步动作、处理人、完成期限及所需配合。原因尚不明确时，可以先安排负责继续核查的人，而不是等全部责任确定后才开展工作。
如果一方暂时无法提供日志或人员，应记录当前证据能够支持到哪一步、还缺少什么条件，并按约定渠道升级，不能直接把“查不到”当成另一方有错的证明。
最需要谨慎的，是“失败了再发一次”
接口超时，不一定代表对方没有执行。采购入库已经写入ERP，但返回信息中断时，直接重新创建可能产生重复记录。
因此，补传前应根据约定的业务标识、查询接口或对账机制核实处理状态。如果接口本身不具备查询能力，需要与对应团队确认替代核查方式，不能默认所有平台都支持同一种处理办法。
幂等可以理解为：同一业务被重复提交时，按约定避免产生重复的业务效果。由哪一端识别、使用什么标识、如何处理重复请求，都需要共同确认，不能只在方案里写上一个术语。
重试也应区分原因。短暂连接异常与字段错误、权限不足不是同一类问题；后者通常需要先修正条件，连续重复调用未必有用，还可能增加接口压力。
失败补偿同样不是简单删除对方记录。有些业务动作已经发生，后续可能需要更正、冲销或人工处理，具体方式应由业务规则和接口能力决定。
联调时应在合适的测试环境中验证重复提交、结果丢失和恢复后继续处理等场景，确认不会因为恢复动作再次制造数据问题。
外部平台有限制，不代表责任可以直接移出项目
ERP、CRM、企业微信、支付或硬件平台，可能具有不同的接入条件和开放范围。接口文档存在，不代表权限、测试账号和网络条件已经就绪。
这些条件应列入接口台账，注明负责联系人、当前状态、取得方式和影响范围。限流、调用时段、测试环境差异及需要第三方协助的事项，也应作为项目依赖单独记录。
如果限制在前期已经明确，需要核对技术方案是否识别了影响，并安排相应处理。例如已约定对限流进行控制，就应检查实现是否符合该约定，而不能只把失败解释为平台限制。
如果第三方后来调整接口，则需要确认变更内容、通知与生效情况，以及原方案受到的影响，再决定修改、适配和复测安排。
涉及新增工作时，应说明与原范围的关系、需要哪些配合、预计影响及费用确认方式。不能简单按照“接口属于谁”来平均分摊，也不能把所有外部变化都直接算作原有缺陷。
技术原因、当前处理动作和费用安排可以分别记录。涉及合同责任或其他争议时，再结合具体约定与相应专业意见处理，不宜仅凭一个错误码作判断。
联调通过，要拿到业务结果，而不只是返回消息
请求发出、平台受理和业务处理完成，可能是不同阶段。对于异步处理，还需要确认最终状态如何查询、通知怎样接收，以及结果缺失时如何核验。
采购入库案例中，应检查ERP是否生成了对应记录，仓库、物料、数量及关联信息是否正确，新系统是否取得并保存了可追踪的处理结果。
除了正常调用，还应结合接口约定检查重复请求、权限不足、字段异常、限流、短暂中断和失败恢复。不是每个接口都采用相同机制，但重要风险应有对应验证。
双方复测需要使用一致的版本、环境、样例和预期结果。发现数据差异时，应根据主责系统和确认规则核对，不能只比较两边页面数量是否相同。
联调结论应写明通过的接口与业务场景、尚未解决的问题、外部依赖和后续负责人。仅完成部分接口，不应笼统记录为“系统集成全部完成”。
字段映射、接口说明、异常处理、对账方式和测试记录，也应纳入交接资料。这样，后续维护人员才能理解某笔业务为什么失败、如何核查，而不是重新寻找当时参与联调的人。
最终需要回答的不是一句“谁负责”，而是哪里出现了偏差、谁完成下一步处理、依据什么结果确认问题已经解决。
相关问题
哪一方接口返回错误，就一定是哪一方负责吗？
不一定。错误可能由调用参数、权限、业务状态、环境或服务实现触发。需要结合两端记录和接口约定定位，不能只看错误出现的位置。
官方样例能够调通，为什么实际业务仍然失败？
样例通常只覆盖特定条件。真实业务可能包含不同数据、权限、调用频率和状态约束，需要使用具有代表性的业务样例继续验证。
第三方暂时不配合，还能继续排查吗？
可以先核对自身请求、配置和现有记录，缩小问题范围。同时明确缺少的证据与配合事项，按项目联系人和升级机制推进，不宜据此直接作出责任结论。
联调排查和新增开发费用怎样区分？
应结合原定服务范围、实际原因和新增工作内容确认。缺陷核查、接入条件补齐、第三方配合及需求变化应分别说明，不宜只用“联调失败”统一定价。