n8n 同步显示成功，数据却漏了一页

n8n 工作流连续三周显示绿色，客户的订单报表却一直漏数据。作者把这次事故概括为「缺了 12% 的行」：API 每页返回 100 条订单，流程只取了第一页；业务量超过每晚 100 条后，第二页就成了报表里的盲区。

这篇文章讨论的不是模型效果，而是 AI 自动化流程里更基础的可靠性问题：请求成功，怎么才能证明数据取全了？作者给出的办法是把分页做成有结束条件、恢复位置和数量核对的循环，再用业务 ID 防止重复写入。

绿色状态为什么掩盖了漏单

作者的流程每晚从 API 拉取新订单，再写进表格。它没有报错，没有超时，也没有部分失败提示。直到客户发现十几笔订单没进入报告，问题才暴露出来。

原因很直接：API 承诺返回一页数据，流程却把这一页当成了全部数据。订单少于 100 条时，这个缺陷不会显现；超过 100 条后，HTTP 请求依旧成功，遗漏却开始积累。

请求成功只能证明拿到了一页，不能证明完成了一次同步。

作者现在要求分页循环依据明确的信号结束：下一页游标为空，或者当前页条数小于请求上限。具体该用哪一种，要看 API 的分页约定，不能自己猜。

如果接口提供总数，就在循环结束后校验 received == total；没有总数，也要记录每次取了多少页，让页数从 1 页变成 3 页这样的变化能够被看见。

分页循环还要解决中断和重复

作者区分了两类分页，因为它们的故障方式不同。

偏移量分页（Offset Pagination）常见形式是 ?page=2、?offset=100。它依赖数据的位置：同步期间如果前面的记录被插入或删除，后续页面的边界就会移动，同一条记录可能出现两次，也可能被跳过去。

游标分页（Cursor Pagination）能缓解这种位置变化带来的问题，但游标也可能过期。作者提醒，失效游标的表现有时会被误判为「已经没有下一页」。

为支持恢复，作者会在每页处理后，把游标或偏移量存进工作流状态，而不是等整次同步结束才保存。按他的设计，处理第 4 页时崩溃，就从第 4 页恢复，避免从第一页重新处理。

重试仍然可能带回旧数据，因此还需要另一层保障：写入前，按源系统提供的记录 id 检查目标端是否已经存在。

「跳过前 N 行」不能替代这种去重。行的位置会变，记录的身份才是核对依据。这也适用于 webhook 重放：同一个事件再次到达，不能因为它出现在新的位置就再次写入。

一次同步至少要报告四个数

作者现在让每次运行报告四项指标：

• 拉取了多少页。
• 收到了多少行。
• 实际写入了多少行。
• 因重复而跳过了多少行。

这四个数把「运行结束」拆成了可以检查的结果。

例如，只拉取了 1 页，收到的行数又恰好等于每页上限，就应该检查是否漏掉后续页面。不过，这只是可疑信号，也可能刚好只有一整页数据，不能直接判定同步失败。

重复跳过数突然增加，则提示流程可能发生过重试，或者分页期间数据位置发生了变化。它不一定代表数据已经出错，但值得进一步追查。

作者最终给出的规则是：分页拉取必须包含结束条件、恢复位置和数量核对。一个返回 100 行的 HTTP 节点，只能证明这 100 行到手了。

我的判断

我认同作者把「执行成功」和「数据完整」分开判断。这种检查成本不高，却能发现异常处理捕捉不到的错误：所有请求都合法，结果仍然不完整。

但这是一篇作者自述的生产事故与修复经验。作者称修复已经测试，却没有提供测试过程、故障注入结果或不同实现的对照数据，不能据此认定方案已经覆盖所有边界。他也在推广 AI Automation Lab 模板，阅读时应把工程建议与产品宣传分开。

两个实现前提尤其需要补齐。首先，游标分页的稳定程度取决于接口契约，不能只看见 cursor 就认定不会漏数据。其次，「每页保存状态」还不够，原文没说清写入数据和保存进度的先后关系：进度先保存、数据后写入，中途崩溃仍可能漏处理。

按 id 查询后再写入也有并发窗口。若两个运行同时查到记录不存在，仍可能重复写入；在支持的存储里，用唯一约束配合幂等写入会更稳妥。接口提供的 total 如果在同步过程中变化，数量核对也需要统一统计口径，原文没有展开。

能拿来做什么

1. 检查现有 n8n 或 Node 同步任务：找到只请求一次列表接口的地方，核实下一页信号、分页上限和结束条件，并用超过一页的数据验证流程。
2. 给订单导入、报表同步增加页数、接收数、写入数和重复跳过数；对「只取 1 页且恰好达到上限」设置检查提示，避免只看绿色状态。
3. 给分页任务保存可恢复进度，并验证写入与保存进度之间发生中断时的行为；重跑后既要检查是否重复，也要检查是否遗漏。
4. 让 AI 编写分页代码时，明确要求按源记录 id 去重，并覆盖空页、整页、重试和游标失效场景，不要只验收正常返回第一页的结果。