你是不是也遇到过：批量处理数据，n8n 跑着跑着就崩了？
兄弟们，我是 N8N大学 的主编。后台最近收到很多私信，都在问同一个问题：为什么我的 n8n 工作流一处理大量数据（比如上千个用户、上千个商品链接），要么直接卡死，要么报错 Execution timeout？
说实话，这事儿太常见了。很多刚接触自动化的兄弟，习惯直接把一个包含 1000 条数据的数组丢给 HTTP Request 节点。结果呢？API 限流把你拒之门外，或者 n8n 自身的内存直接爆掉。这就是典型的“一口气想吃成个胖子”，最后噎着了。
今天，笔者就手把手教你 n8n 中处理批量数据的“必杀技”—— Split In Batches（分批处理）。学完这篇，别说 1000 条，跑 1 万条数据也能稳如老狗。
核心实操：Split In Batches 节点保姆级教程
别看这名字洋气，其实它的逻辑非常简单：**排队，一次只放 N 个人进来**。我们直接上实战，假设我们要给 1000 个用户发送邮件（或调用 API），为了不把服务器干废，我们决定每次只处理 50 个。
第一步：准备数据源 (Set 节点)
首先，我们需要模拟这 1000 条数据。在实际工作中，你的数据可能来自 Google Sheets、Airtable 或 Webhook。为了演示，我们用 Set 节点模拟一个包含 1000 个对象的数组。
在 Set 节点的 Properties 中，添加一个字段，比如叫 items，值设为 [{{ $runIndex }}]。为了模拟 1000 条，我们可以手动复制粘贴，或者用一些简单的 JS 生成（这里为了篇幅，大家理解是 1000 条数据的数组即可）。
关键点： 确保你的输出是一个标准的 JSON 数组，格式像这样：[{"id":1}, {"id":2}, ..., {"id":1000}]。
第二步：插入“分流大坝” (Split In Batches)
这是今天的主角。在 Set 节点后面，直接拖入一个 Split In Batches 节点。
这个节点的配置非常简单，只有一个核心参数：
- Batch Size (批次大小)：这里填 50。意思就是每次循环只提取 50 条数据进入内部流程。
- Wait (等待时间)：通常留空即可。除非你的 API 有严格的每秒请求限制，否则不需要填。
连接好之后，你会发现这个节点下方自动多出了一个输出端口，通常叫 Set 或者你上游节点的名字。这就意味着，接下来你要连接的节点，只会收到 50 条数据，而不是 1000 条。
第三步：执行你的操作 (HTTP Request / Email 节点)
现在，在 Split In Batches 的输出端口后面，连接你真正要执行操作的节点，比如 HTTP Request。
配置 HTTP Request 时，你需要引用当前批次的数据。比如你要发送 POST 请求，Body 里可以这样写：
{{ $json.items }}
这时候，$json.items 代表的不再是 1000 条，而是当前的 50 条。n8n 会执行完这 50 条，再回头去取下一批 50 条，直到数据被取光。
第四步：处理返回结果 (可选)
如果你需要记录这 1000 条数据的处理结果，可以在 HTTP Request 后面接一个 Aggregate 节点。它的作用是把每一次循环产生的结果“收拢”在一起，最后输出一个完整的列表。
实战避坑指南：这 2 个细节决定成败
虽然 Split In Batches 很好用，但笔者见过太多兄弟在细节上翻车。以下两个坑，千万别踩：
坑点一：循环死锁 (无限循环)
如果你把 Split In Batches 的输出直接连回了它自己，或者形成了某种逻辑闭环，且没有退出条件，工作流就会陷入死循环，直到超时崩溃。记住，它是一个“漏斗”，不是“圆环”。
坑点二：忽略了 API 的 Rate Limit (速率限制)
你以为分批了就万事大吉？错。如果你设置的 Batch Size 是 50，但你的 API 接口限制“每秒最多请求 10 次”，n8n 会在 1 秒内瞬间把这 50 个请求发出去，结果就是账号被封。
解决方案： 在 Split In Batches 和 HTTP Request 之间，插入一个 Wait 节点。设置等待 1 秒（或者根据你的 API 文档计算），强制给每次批次之间加个冷却时间。
FAQ：关于循环节点的灵魂拷问
Q1：Split In Batches 和 IF 节点里的循环有什么区别？
完全两码事。IF 节点里的循环通常用于简单的逻辑判断，而 Split In Batches 是专门为了处理大量数据流设计的。它能有效管理内存，防止 n8n 实例因为一次性加载太多数据而崩溃。处理大数据，请无脑选 Split In Batches。
Q2：我处理了 1000 条数据，怎么知道中间哪条失败了？
n8n 的执行历史记录非常强大。虽然整体工作流显示成功，但你可以点开 Split In Batches 的每一次循环记录。如果某次循环里的 HTTP Request 报错，那一次循环的记录里会有红色提示。建议在操作节点后加一个简单的判断，如果失败则记录到 Google Sheets 或发邮件通知你。
Q3：Batch Size 到底设多少合适？
这是一个平衡题。设太小（如 1），处理 1000 条会非常慢；设太大（如 1000），又容易超时或被封。通常建议从 10 到 50 开始尝试。如果你的 API 响应很慢，Batch Size 设小一点；如果响应很快，可以设大一点。
总结与资源
处理大量数据的核心在于“分而治之”。不要试图一次性把所有数据都塞进 n8n 的内存里，利用好 Split In Batches 节点，让它像流水线一样，一批一批地稳定处理。
我是 N8N大学 的主编，希望这篇教程能帮你解决实际问题。如果你在搭建过程中遇到其他报错，欢迎随时来 n8ndx.com 找我交流。记住，自动化不是为了炫技，而是为了让我们早点下班。
