你的 n8n 工作流为什么跑着跑着就“卡死”了？
笔者在 N8N大学 社区里，几乎每天都能看到类似的问题截图：
“我的工作流处理 5000 条数据，跑到第 2000 条就报错退出了。”
“日志里全是 ‘JavaScript heap out of memory’，明明机器内存还有剩啊？”
这就是典型的 内存溢出 (Memory Leak) 问题。在 n8n 中，当你需要处理成千上万条数据（比如批量爬虫、大规模数据清洗）时，如果直接让数据流“跑”过整个工作流，n8n 的内存会被迅速耗尽，最终导致 Node.js 进程崩溃。
解决这个问题的神器，就是 SplitInBatches 节点。但很多人只知道把它挂上去，却不懂背后的逻辑，结果还是翻车。今天，笔者就带你彻底搞懂如何用它来实现“工业化级”的批量处理。
一、核心原理：为什么 SplitInBatches 能救你的内存？
在深入实操前，我们得先用大白话理解它的运作机制。
普通的 n8n 工作流是线性执行的。如果你在 Start 节点接收了 10,000 条数据，这些数据会像洪水一样瞬间涌向后续的每一个节点。如果你的后续节点（比如 HTTP Request 或 Code 节点）需要在内存中暂存数据，或者 n8n 本身为了追踪状态，内存占用就会瞬间飙升。
SplitInBatches 的作用就像一个“水坝”或者说“漏斗”。它把 10,000 条数据切分成一个个小批次（Batch）。比如每批 100 条，它只让这 100 条数据流经后续的处理逻辑。处理完一批，清空内存，再放下一批。
这就是它避免内存溢出的根本原因：限制同一时间驻留在内存中的数据量。
二、最佳实操：3 步配置 SplitInBatches
很多新手只是把 SplitInBatches 节点拖出来连上线，参数全是默认，这在生产环境是极其危险的。以下是 N8N大学 推荐的标准配置流程。
步骤 1：确定“批次大小” (Batch Size)
这是最关键的参数，直接决定了内存占用和执行速度的平衡。
- 位置：SplitInBatches 节点 ->
Parameters->Batch Size - 建议设置：
- 如果是 HTTP 请求（受限于 API 并发）：建议 10 ~ 50。
- 如果是 纯数据计算：建议 100 ~ 500。
- 如果是 数据库写入：建议 500 ~ 1000。
笔者的避坑经验： 不要盲目追求大数值。笔者曾测试过，在 2GB 内存的服务器上，如果单次批次处理超过 500 条包含大字段的 JSON 数据，n8n 依然会 OOM（Out of Memory）。建议从 50 开始测试，逐步增加。
步骤 2：正确处理“循环”与“输出”
SplitInBatches 的连接方式很容易搞错，导致死循环或数据丢失。
- 数据入口：上流节点（如 Start 或 Webhook）连接到 SplitInBatches 的
Input。 - 处理出口：SplitInBatches 的
Output连接到你的处理节点（如 HTTP Request, Set, Code）。 - 循环入口（关键！）：处理节点的输出必须连回 SplitInBatches 的
Looping端口。
逻辑解析： 数据从 Output 出来 -> 经过处理 -> 回到 Looping -> SplitInBatches 判断是否还有下一批 -> 有则继续从 Output 推出数据 -> 无则从 Done 端口流出。
步骤 3：利用“Options”进行降速保护
如果你的批量处理涉及调用外部 API，对方通常有速率限制（Rate Limit）。如果不加控制，n8n 会瞬间把对方 API 打爆，导致你的 IP 被封。
在 SplitInBatches 节点的 Options 中：
Wait Amount：等待时间数值。Wait Unit：等待时间单位（秒、毫秒）。
例如，设置 Wait Amount: 1000 和 Wait Unit: Milliseconds，意味着每处理完一批数据，n8n 会暂停 1 秒再拉取下一批。这不仅保护了目标 API，也给你的服务器留出了喘息时间。
三、进阶技巧：结合 Code 节点进行手动分片
虽然 SplitInBatches 很好用，但在极高并发场景下，它依然可能成为瓶颈。N8N大学 推荐一种更硬核的玩法：Code 节点预处理 + SplitInBatches。
如果你的数据源是 JSON 数组，且逻辑允许，我们可以先在 Code 节点中用 JavaScript 的 slice 方法手动切分。
// 伪代码示例：在 Code 节点中
const allData = $input.all();
const chunkSize = 100;
const chunks = [];
for (let i = 0; i < allData.length; i += chunkSize) {
chunks.push(allData.slice(i, i + chunkSize));
}
return chunks;这种方法配合 SplitInBatches 使用，可以更精细地控制数据流向，尤其是在处理非标准数据结构时。
四、常见报错与解决方案
即便配置正确，有时依然会遇到问题。以下是两个高频报错：
1. JavaScript heap out of memory
原因：批次大小（Batch Size）设置过大，或者后续节点（如 Code 节点）在处理过程中产生了额外的大对象，导致内存泄漏。
解决：
- 将 Batch Size 减半，重新测试。
- 检查 Code 节点，避免使用全局变量存储大量数据。
- 如果是 Docker 部署，尝试给容器增加内存限制（但这只是延缓问题，核心还是要优化批次大小）。
2. Workflow hangs / stuck
原因：Looping 连接形成了死循环，或者某一批数据处理卡住（例如 HTTP 请求超时设置过长）。
解决：
- 检查连线：确保只有处理节点的输出连回了 SplitInBatches 的 Looping。
- 设置超时：在 HTTP Request 节点的 Options 中设置 Timeout，防止无限等待。
五、FAQ：你可能还想问
Q1: SplitInBatches 和 Split In Batch 节点有什么区别？
A: 早期 n8n 只有一个 Split In Batch 节点，功能较老。新版 n8n 统一使用 SplitInBatches，逻辑更清晰，建议始终使用新版节点。
Q2: 处理 10 万条数据，我的服务器需要多大内存？
A: 这取决于 Batch Size。如果你设置为 100，n8n 同时只在内存中处理 100 条数据，加上 Node.js 进程开销，通常 2GB 内存的 VPS 就能跑得很稳。关键在于“分批”，而不是堆硬件。
Q3: 为什么我的数据流到了 SplitInBatches 的 Done 端口，但数据量变少了？
A: 检查你的 Looping 连线是否正确。如果数据直接从 Input 走到 Done，说明没有形成循环处理逻辑。确保处理节点的输出回到了 Looping 端口。
总结与资源
处理大数据流是 n8n 自动化进阶的必修课。SplitInBatches 不仅是一个节点，更是一种“分而治之”的工程思维。记住 N8N大学 的核心口诀：小批次、控延时、勤监控。
如果你想深入学习更多 n8n 硬核技巧，欢迎访问 N8N大学 (n8ndx.com)，这里有更多实战案例等你探索。
