n8n 处理多条数据要不要循环：逐项执行、批次与分页的区别

先数清输入中的 item 一份 JSON 对象中的数组，与节点输入面板中的多个 item，不应只凭外观当成同一件事。先查看节点实际收到多少条数据，再观察一次执行输出多少条结果。若节点已经逐项工作，再套一层回连循环可能重复处理相同记录。 同样三个订单，输入形状会改变处理方式 三条 item 分别携带 O1、O2、O3 时，多数普通节点会逐项处理；只有一条 item，里面是 {"orders":[{"id":"O1"},{"id":"O2"},{"id":"O3"}]}，则仍然是一条输入。先决定是否需要把内部数组拆成多条 item，或让处理逻辑明确遍历 orders，不能只看到三个订单就认为下游会发出三次调用。 为订单加上可辨认的 ID 后，检查每一步实际经过哪些 ID。如果输出只有 O1，核对 Execute Once；如果 O1—O3 出现多次，检查节点本来的逐项处理与外层循环是否叠加。数量异常时先观察数据形状，比反复修改 Batch Size 更有效。 默认迭代和例外 官方循环指南说明，大多数 n8n 节点会为输入项执行处理，但存在节点或操作例外。Code 的 Run Once for All Items 等模式就需要按整体输入理解。遇到少处理或重复处理时，应同时核对节点类型、操作及运行模式，而不是直接增加循环。 Execute Once 不等于批处理 节点设置中的 Execute Once 用于只处理第一项。它适合明确只需一次动作的场景，却不适合用来“先试一批”而期待后续项目自动完成。测试时可以给每条输入加上容易辨认的身份，确认哪一条实际进入后续步骤。 需要控制批次时怎么做 Loop Over Items 将输入分成批次，Batch Size 为 1 时逐项处理。官方说明，全部输入分批完成后节点会停止，不需要再为这类有限集合增加 IF 作为结束条件。若对接服务有速率限制，可结合实际允许的节奏安排批次与等待，但仅设置批大小并不等于满足每秒请求限制。 例如五条测试记录、Batch Size 为 2，预期处理三批：2、2、1。每批处理链完成后应回到 Loop Over Items 继续领取下一批，全部结束后的汇总接在完成出口。把最终汇总错误地接在逐批路径上，可能每批都发送一次“全部完成”；遗漏回连则可能只处理第一批。 持续循环要有可验证的出口 另一类需求是“直到条件满足再停止”。官方示例通过回连前一个节点并加入 IF 判断形成循环。编辑建议记录每轮状态，并设置业务上的尝试边界；对始终没有变化的响应给出明确退出原因，避免流程不停运行却没有进展。 分页属于取数逻辑 返回第一页不代表全部数据已经进入输入项。分页接口要核对下一页标识、页码或游标，以及服务提供的结束信号。应按所用 HTTP 节点的分页配置或循环方式实现，再用末页为空、总数刚好整页和中途失败三个场景检查，不能从一次成功响应推断采集完整。 若分页服务用 next_cursor 表示下一页，应保存本轮使用与返回的游标。自拟样例可设为第一页返回 c1，第二页返回 c2，第三页返回空游标结束；再测试服务错误地重复返回 c1，确认流程有停止或告警条件。是否用空页、游标为空或 has_more=false 结束，必须以该接口契约为准，不能混用不同服务的约定。 完成后的验收 保存源记录数、处理身份与结果数，重点检查每个业务对象是否恰好完成一次。输入数量、批次数和外部请求次数可能不同，把它们分别记录，后续遇到限流或重复写入时更容易定位是哪一层出了问题。

本篇涉及的工具1

n8n

控制逐项处理、分批和条件循环

适合场景

需要批量处理记录、控制请求节奏或读取分页接口的 n8n 使用者。

需要留意

需区分节点运行模式与外部接口分页规则。

了解项目 访问官网