简介

当 n8n 工作流接收到一个项目列表——例如来自电子表格的 500 行数据或来自 API 的 1,000 个联系人——如果天真地将每一个都直接发送给下一个节点，可能会引发各种问题：速率限制、超时、内存飙升或数据库表被锁。SplitInBatches 节点通过将列表拆分为较小的组、一次释放一批来解决这个问题，让下游节点在各组之间得到喘息。

你可以把它想象成一条可控的传送带：不是一次把 1,000 个箱子堆给一个工人，而是每次只喂 50 个。

SplitInBatches 的工作原理

SplitInBatches 位于数据源与处理每个项目的节点之间。第一次执行时，它发出第一批（大小可配置，默认 1 项），然后暂停；后续执行时再发出下一批，直到列表耗尽。每个批次都经过相同的下游分支，因此通常会与 Set、HTTP Request 或数据库节点配合使用。

该节点有两个重要的输出："Done" 在最后一批释放后触发一次——可用于最终汇总或清理步骤；"Loop" 则将下一批反馈回你的处理分支。

基础配置

打开节点，根据下游服务能承受的能力设置 Batch Size。对于大多数限制为每分钟 100 次请求的 HTTP API，Batch Size 设为 10、并在批次之间使用 Wait 节点等待 6 秒，通常效果很好。

{
  "node": "SplitInBatches",
  "parameters": {
    "batchSize": 10,
    "options": {}
  },
  "type": "n8n-nodes-base.splitInBatches"
}

将 "Loop" 输出连入你的处理节点，然后从该节点再连回 SplitInBatches，以便释放下一批。将 "Done" 输出连接到你需要的任何汇总步骤。

实际示例：将联系人推送到外部 API

假设你从 CRM 拉取了 200 个联系人，需要将每个联系人都 POST 到一个 webhook。如果不分批，你会瞬间发出 200 个请求，很可能触发 429 Too Many Requests 错误。

工作流如下：Cron 触发器每天触发一次，HTTP Request 节点拉取联系人，SplitInBatches 将其按 10 个一组分批，每批进入一个循环，对每个项目调用 webhook，然后 Wait 节点暂停 6 秒，之后控制权返回 SplitInBatches 处理下一批。所有批次处理完毕后，"Done" 分支向 Slack 记录 "Synced 200 contacts"。

🖥️ [建议在此处插入示意图：完整循环迭代生命周期图——SplitInBatches 释放批次 → 处理节点处理项目 → Wait 暂停 → 返回 SplitInBatches → 重复直至 Done 分支触发]

常见错误

忘记把循环连回去是最常见的错误——没有这条连线，工作流在第一批之后就会停止。另一个常见失误是将 Wait 节点放在 SplitInBatches 之后，而不是放在循环分支内部；这样就失去了限流的意义，因为批次之间并不会产生等待。最后请记住，SplitInBatches 的状态是按每次执行持有的，因此每次新的触发运行都会从第一批重新开始——你无法在不同的执行之间恢复一个未完成的批次循环。

小结

当下游服务无法一次性消化你的完整列表时，SplitInBatches 就是首选节点。根据目标 API 的速率限制设置合理的 Batch Size，务必把 Loop 输出连回去，并在循环内部搭配 Wait 节点以实现友好的限流节奏，使用 "Done" 分支进行运行结束后的清理工作。

对于超过几百项的列表，或需要并行处理的情况，请改用 Loop 节点或带有 Execute Workflow 触发器的子工作流——这些内容将在后续课程中介绍。