CRM接口失败后怎么补数据？先分错误类型，再用幂等、死信和对账恢复

客户已经在ERP创建，却没有进入CRM；合同已回写一次，超时重试后又多出一份；接口恢复后任务全部重放，把下游压垮。此类问题不能靠“失败就重试三次”解决。恢复流程必须先判断错误是否可重试，再保证重复请求不会重复生效，把永久失败隔离，并用业务对账证明缺口真的补齐。

先按可恢复性分四类错误

Microsoft的瞬时故障指南建议有限重试，并将重试与熔断配合，避免持续请求已故障的依赖；无效请求、权限问题和业务冲突通常不会因等待而自行恢复。错误分类应落到可查询字段：接口名、业务对象、请求ID、业务主键、错误码、首次与最后失败时间、尝试次数和当前责任人。

幂等键是补数据前的第一道门

写入请求必须携带稳定幂等键，例如“源系统＋对象类型＋源记录ID＋业务版本”。接收方先记录键和处理结果，再执行业务写入；重复请求返回原结果，不新建第二条客户、跟进、合同或回款。若一次请求包含多步，每一步都要能判断是否已经完成。

仅用创建时间或手机号查重不可靠：时间会变化，手机号可能共享或缺失。Microsoft关于异步请求的架构说明建议通过幂等键防止网络故障造成的重复提交；其微服务评估资料同时建议使用关联ID串联跨服务日志。

重试必须有预算，不允许形成重试风暴

• 同一请求限定最大次数和最大持续时间；
• 使用指数退避并加入随机抖动，遵守对方Retry-After；
• 全局设置重试预算，避免大量请求各自少量重试仍压垮下游；
• 超过阈值打开熔断器，停止调用并进入降级或排队；
• 探测恢复后小批放量，不一次重放全部积压。

Microsoft的Retry Storm反模式指出，无限或高频重试会阻碍服务恢复。CRM场景中，最危险的是订单、合同、库存与回款等有副作用的写操作；未确认幂等前，不得通过批量重放“碰碰运气”。

死信队列要保存恢复所需最小证据

死信记录保存业务主键、关联ID、请求摘要、错误分类、规则版本、尝试次数和责任队列；敏感字段按最小必要原则脱敏或引用受控原文。永久失败进入死信，不继续消耗重试资源。Azure后台任务最佳实践建议区分瞬时与永久失败，并将持续失败消息转入死信队列。

死信不是垃圾桶。每条记录必须有状态：待分析、待数据修复、待配置恢复、可重放、需人工补偿、已关闭；关闭前保存修复方式与业务回读证据。

补偿不是简单删除，要按业务不可逆点处理

若CRM已创建客户但ERP合同失败，未必应该删除客户；若合同已审批、消息已发送或发票已开具，也不能用数据库回滚假装没有发生。Microsoft的补偿事务模式强调，补偿动作依赖业务规则，可能无法完全恢复到初始状态，并且补偿本身也要幂等、可监控和可续跑。

用四本账证明恢复完成

第一本是发送账：应发送数、成功投递数、明确拒绝数；第二本是接收账：已接收、已处理、重复拦截、死信；第三本是业务账：源对象与目标对象的数量、主键、关系、金额和状态；第四本是异常账：未解决、人工处理、补偿完成与关闭原因。

基础公式为：应处理数＝成功数＋明确拒绝数＋待处理数；再核对业务缺口＝源端有效记录－目标端正确且可回读记录。成功HTTP响应只能证明接口层接收，不证明业务对象正确落库。数据迁移对账方法可参考CRM数据迁移清洗与验收，开放接口权限可参考CRM开放平台验收清单。

恢复演练用五条故障验证闭环

1. 模拟下游超时但实际已写入，确认重试不会重复；
2. 提交字段非法记录，确认直接进入死信而非无限重试；
3. 模拟令牌失效，确认熔断、告警和恢复探测；
4. 构造状态版本冲突，确认旧消息不会覆盖新状态；
5. 积压一批任务，小批重放并完成四本账对账。

若故障发生在上线切换窗口，应与CRM上线切换与回退门禁联动；企业微信接入范围和异常责任可结合企业微信CRM集成费用拆解确认。

CRM接口已有漏数、重复或积压？申请CRM集成故障诊断，先用错误分诊、幂等和对账定位恢复边界。

主要信息来源

• Microsoft Azure Architecture Center：Transient Fault Handling
• Microsoft：Retry Storm Antipattern
• Microsoft：Compensating Transaction Pattern
• OWASP：Unsafe Consumption of APIs