n8n 处理一千条数据中断，怎样从检查点继续

n8n 处理一千条数据中断后，不能简单从“第五百条”继续，因为排序变化、部分完成和写后断线都可能让位置失真。应先固定本次输入集合，再保存每条业务 ID 的处理状态和批次检查点，恢复时以持久结果为准。本文用合成小样本说明同样适用于大批量任务的设计，未对真实千条任务做性能测试。

把本次任务的集合冻结下来

启动前建立任务号，记录筛选条件、源数据截止时间、排序规则和输入清单摘要。若接口支持快照或稳定游标，优先按其契约使用；否则把需处理的 ID 固化到任务账本。只保存页码不足以恢复：任务中断期间新增或删除记录，会改变下一页内容。任务重新开始时使用同一清单，新增数据进入下一任务，不与旧批次混在一起。

演示任务 batch_demo_01 包含十个合成订单，每批三个。每项记录订单 ID、输入版本、状态、输出位置和最后尝试时间；批次记录游标、已完成数、未知数与检查点版本。目标不是为每个节点保存全部大对象，而是保留足以判断是否需要重做的证据。大文件可保存受控引用与摘要，避免任务账本变成另一份难以清理的客户资料库。

分批节点不会自动替你定义检查点

n8n Loop Over Items 官方文档说明，该节点按批输出输入项，完成时通过 done 输出汇总处理数据。这个机制有助于控制批次，但业务检查点何时落盘、进程重启后如何重新选项，仍需单独实现。不要把一次执行中的循环位置当作经过恢复验证的持久任务状态。

建议先标记单项领取，再处理，再保存可核对的结果，最后推进批次检查点。若检查点先推进而结果未落盘，中断后容易漏项；若结果先成功而检查点未推进，恢复时可能重复，但可以通过逐项状态和下游幂等机制识别。跨两个系统很难用一个本地事务包住全部动作，因此设计中必须有结果未知状态，而不是只保留成功与失败两种。

按一个可解释的中断点演练

下载分批与恢复演练表，记录为合成数据。第一批三项完成，第二批的第四项完成，第五项写入后响应中断，第六项尚未开始。恢复时跳过前四项，第五项先查询下游，第六项继续领取。这里“从第二批继续”不是重跑整个第二批，更不是把第五项直接当失败再写一次。每个决定都能由表中的状态与业务回执解释。

先用只写测试账本的处理器演练，再分别在领取后、下游写后和检查点提交前制造中断。重启执行时读取相同任务号，检查是否错误建立新任务。为了防止两个恢复执行争抢同一项，领取动作要有并发控制与过期审查。过期领取也需要先核对下游结果，租约到期本身不能证明没有完成业务写入。

恢复时同时检查权限与数据版本

长任务可能跨越授权变化。某员工发起的批量更新，恢复时不能因任务早已批准就忽略其权限已经撤销。写操作需要确认原批准覆盖本次对象和字段，输入版本变化时重新预览，权限不足项进入人工队列。只读导出也要核对数据可见范围，不能把原来能看的全部资料继续交付给权限已变更的人。

单项失败不一定终止整批。可以把格式错误送入例外清单，继续处理独立项；但如果源系统权限异常或输出目标不可用，应暂停整个任务，避免一千条都重试同样的问题。设置任务截止时间、错误上限和取消入口。用户取消后，已经完成的动作不自动撤销，应明确完成数、未处理数及需要人工补偿的对象，防止以“取消成功”掩盖既成修改。

用集合对账证明没有漏和重

验收时比较输入 ID 集合与终态集合，检查是否存在无状态项、重复输出、未知结果和同 ID 多版本。计数相同不代表集合相同：少一条又重复一条也能凑出相同总数。最终清单应说明完成、跳过、拒绝和待人工各多少，并保留每项原因。性能验收则另行以目标环境测量批次大小、执行时长和存储增长，不能从小样本推算生产吞吐。

对于生成文件的任务，还要避免把半成品交给下一步。可以把单项输出写到临时位置，核对大小、格式和摘要后再登记完成；整批清单只引用确认过的结果。恢复时既检查状态表，也确认输出文件确实存在且属于本次输入版本。文件丢失但状态显示完成，应标为待修复，不能静默跳过。若任务有先后依赖，例如先建主记录再建明细，应把依赖关系写进账本，独立并行的恢复规则不能直接套用。交付中说明哪些项可重算、哪些有外部副作用，接手人员才能正确选择重做范围，而不是凭执行截图决定。任务清单和例外处理应由接手者共同签认。

更多背景见n8n 专题和Agent 节点边界，取数不完整应先处理分页完整性核对。如需为现有批量导出、建单或资料处理增加恢复能力，可在定制咨询提供输入规模、稳定 ID、写入接口和可接受中断时间，评估检查点及恢复演练范围。