分批处理并保存进度

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你要导入 120 条教学记录，选择每批 50 条且已确认不超当前服务限制。前两批 100 条已确认，第三批 20 条中 5 条确认成功、5 条明确失败、10 条结果未知。中断后不能把整个任务重做，也不能把未知当未写入。

具体做法

固定请求清单与稳定记录身份，每批保存逐项确认、失败、未知和续接信息。恢复先核对检查点与外部结果：跳过已确认项，明确失败按契约处理，未知先对账或按已验证的幂等规则恢复。结果列表覆盖每个请求 id，再推进下一批，不用一个批次状态掩盖混合结果。

反例

第三批失败后重新导入全部 120 条，并把没收到结果的 10 条当不存在，创建新记录直到响应成功。

改进写法

记录上述逐项状态：105 条已确认、5 条失败、10 条未知，保留服务返回身份及本地清单映射。恢复排除 105 个已确认项，处理明确失败；未知先核对目标或使用已核验的幂等契约，不盲目重建。每批更新检查点与未决列表，记录所有 120 条，不因恢复重新创建完整任务。50 是本例批次选择，不当成所有服务上限。

为什么这样改

检查点保留已经确认的工作，逐项状态则处理一批内的部分成功。它既减少重复，也防止一个超时把已经发生但未确认的写入变成新的重复对象。

如何验证

教学恢复清单应有 15 条未决，但其中 10 条先进入对账而非直接重试；105 个确认 id 不再创建。最终确认数、失败数和未知数应合计 120。

检查实际目标身份和逐项结果，不仅比较计数；本篇没有导入真实潜客。

适用边界

检查点本身不提供恰好一次交付，需接收端唯一性、幂等或对账支持。导出与导入的续页契约也不同，服务生成的资源 id 不应被本地调度标签替代。冻结批次建议不是当前通用限制。