只对接口不对数据
双方接口都能通，但客户编码、物料口径、单位不一致，跑起来数量对不上。识别信号是联调用例只验状态码不验业务值；纠正要先对映射表，再做业务值比对，业务方也会质疑数据的真实准确性，评审也更难通过。
超级账号打通
为省审批用管理员账号直连，权限过大且日志无法归因。一旦发生数据异常，既查不到人，也无法证明未越权访问，调查往往停在第一步，只能全量重查，改动越晚成本越高，事后追溯起来也更困难，治理也更费劲。
缺幂等与重试
网络抖动触发重试，重复写入生成重复单据。应在写接口引入幂等键，重试前先查状态，并限制重试次数与退避策略，否则越重试数据越乱，合规评审也很难通过，往往要等到月末对账时才会暴露，修复也更贵。
大爆炸式切换
一次性全量上线，出问题只能停业务。应先影子运行或小批量灰度，用数据比对确认一致，再逐步放量，每一步都留一个可回退的版本，节奏要慢，补数脚本也要留档，回退也要能在当天之内完成，灰度也更稳。
忽略上游变更
源系统升级接口字段，集成侧静默失败，几天后才发现数据缺失。应建立变更通知机制与契约版本管理，把接口变更纳入双方的发布流程，灰度指标要提前定，并把每次接口变更写进发布清单，责任也更清楚。
适用与不适用
适合谁
- 正在联调、想提前排雷的项目组与实施方
- 上线后出现数据不一致的企业，需要对账
- 多厂商协作、变更频繁的系统环境，且需对账
不适合谁
- 单系统内部改造、不涉及跨系统调用的项目
- 仅做离线数据导出的一次性任务，不涉及回写
典型场景
某企业的报销单同步上线后出现重复单据。排查发现重试没有幂等键，网络超时后重复提交。团队补了幂等键与状态查询，并对历史数据做去重，之后同类故障未再出现，团队把幂等检查写进了接口规范，复盘也有了依据。
可执行步骤
- 联调用例加入业务值校验，不只验状态码与返回结构，并留用例，并标注预期
- 梳理账号权限，把超级账号换成最小权限服务账号，并登记台账，并定期复核
- 为写接口补幂等键，并设定重试上限与退避策略，写进契约，并写明重试上限
- 设计灰度批次与逐日数据比对方案，明确停止条件与回退动作，并留比对记录
- 与上游约定变更通知方式与契约版本管理规则，写入双方流程，并指定对接人
常见坑
- 联调只测通不通，不测数值对不对，上线对账时才发现大量错配，修复要逐条核对，工期也被拖长，返工也更贵。
- 把重试当万能药，越重试数据越乱，最后只能人工逐条修，工期被拖长，返工也多，对账压力更大，对账也更难。
- 灰度只看错误率，不看业务数据一致性，问题被平均值掩盖，回退时才发现已经扩散，处置更被动，业务方也会质疑评估方法。
- 上游升级未通知，集成静默失败数日，用户投诉才发现，排查范围很大，客诉随之上门，信任也很难恢复。
自检与验收清单
- 映射表是否先于联调确认并签字并存档，且有版本
- 是否仍有超级账号在使用，并有台账可追溯，且定期复核
- 写接口是否都有幂等键与重试上限，并可核对，且可演练
- 灰度是否包含逐日数据比对与差异处理，且有记录
- 上游变更是否有通知与版本机制，责任到人，且有时限
常见问题
联调通过就代表集成成功吗？
不代表。联调多验证连通性与正常路径，业务值一致性、异常路径与灰度表现才决定能否上线，建议逐项留证，避免上线后无法复盘，也便于界定责任，也便于后续验收与复盘。
幂等键怎么设计？
用业务唯一标识，例如单据号加版本，作为幂等键，服务端记录处理状态，重复请求返回同一结果，而不是重复执行。键的选择要能覆盖重试与并发两种场景，也能减少重复单据。
上游不配合改接口怎么办？
先用中间库或适配层隔离差异，同时由客户方推动厂商排期。适配层要写清维护责任与下线条件，避免长期无人负责，变成新的技术债，也便于交接，后续维护也有据可依，方法也更清楚。