SplitInBatches 卡住了？别慌，这是 n8n 里的“常见病”
作为 N8N大学 的首席主编，我见过太多新手在 SplitInBatches 这个节点上翻车。明明逻辑很简单——把一堆数据拆开，分批处理——结果一运行，要么直接报错，要么流程卡死不动。
这种挫败感笔者太懂了。你盯着屏幕，看着那个转圈的进度条，心里想的是“我明明照着教程做的啊”。别急，这通常不是你的逻辑问题，而是配置细节没扣到位。
今天，我就带大家硬核拆解 SplitInBatches 的三个核心排查点。跟着做，保你药到病除。
报错复现：你遇到的是哪种“卡壳”？
在动手修复前，我们得先确认症状。SplitInBatches 的报错通常分两种：
- “硬报错”：运行直接中断，控制台抛出红色错误日志，提示参数缺失或数据格式不对。
- “软卡死”：流程一直在跑，但就是没输出，或者进度条永远停在某个百分比。
无论是哪种，90% 的问题都出在以下这三个配置环节。请打开你的 n8n 工作流，我们开始排查。
第一处：Batch Size（批次大小）—— 别贪多，也别太少
这是最基础也是最容易被忽视的参数。很多新手看到“Batch Size”，下意识就填个“100”甚至“1000”，心想一次处理完多省事。
这里有个坑：Batch Size 决定了每次循环请求 API 或数据库的负荷量。
- 填太大：如果你的下游节点（比如 HTTP Request）处理能力跟不上，或者外部 API 有速率限制（Rate Limit），n8n 就会报
429 Too Many Requests或直接超时。 - 填太小：比如设为 1，虽然安全，但会触发大量的空循环，导致流程效率极低，看起来就像卡死了。
排查建议： 如果你处理的是常规 JSON 数据，建议从 10 到 50 开始测试。如果是调用敏感的外部 API，请务必查阅对方的文档，将 Batch Size 控制在对方的速率限制范围内。
第二处：Loop On（循环条件）—— 这里的逻辑陷阱最深
这是 SplitInBatches 的灵魂所在，也是最容易报错的地方。很多用户在这里配置错误，导致无限循环或直接报错。
n8n 的机制是：当“Loop On”指定的字段不再变化，或者数据量耗尽时，循环才会结束。
常见的错误配置如下：
- 字段名写错：如果你的输入数据是
{{ $json.items }}，但你在 Loop On 里填了data，n8n 就找不到循环的依据，直接报错。 - 留空导致死循环：如果不填 Loop On，n8n 会默认尝试循环所有数据，但如果你的输入是单条数据且没有结束标志，它可能会一直运行直到超时。
实战技巧： 笔者建议，无论数据结构如何，显式指定循环字段。如果你是从上一个节点（如 Read Binary File 或 HTTP Request）获取的数组，确保 Loop On 填写的是 数组所在的路径，通常是 data 或 results。
第三处：输出设置（Output Settings）—— 别让数据“烂尾”
解决了输入和循环，最后一步是输出。SplitInBatches 有两个输出端口：一个是 每批处理完的数据（Output），一个是 循环结束后（Done）。
报错通常发生在 Output 端口的连接上：
- Output 端口悬空：如果你的 Output 端口没有连接任何节点，n8n 可能会报错，或者在日志里显示警告，提示你数据没有被消费。
- Done 端口逻辑缺失：很多用户只连了 Output，忘了连 Done。当批次跑完后，流程没有明确的结束动作，导致状态显示一直“Running”。
正确姿势： 确保 Output 端口连接了真正执行任务的节点（如 HTTP Request、Set 或 Write Binary File）。而 Done 端口通常连接一个 Set 节点来标记任务完成，或者连接一个 Webhook 节点通知外部系统。
进阶排查：如果以上三点都对，还报错怎么办？
如果你按上述步骤检查了配置，问题依旧存在，那可能是更深层的原因：
- 数据格式污染：输入数据中混入了非数组结构。n8n 处理非数组数据时非常脆弱。建议在
SplitInBatches之前加一个 Set 节点或 Code 节点，强制将数据转换为数组格式。 - 内存溢出（OOM）：虽然 SplitInBatches 是为了分批处理，但如果你输入的数据量本身巨大（例如几万行的 CSV），在拆分阶段就会消耗大量内存。解决方案是使用 Read Binary File 节点配合流式读取，或者在 n8n 的环境变量中增加内存限制。
FAQ：你可能还想问这些
Q1: SplitInBatches 和 Loop 节点有什么区别？
A: 简单来说，SplitInBatches 是“批量处理”，适合对大量数据做同样的操作（如批量发邮件）；而 Loop 节点更偏向于“遍历”，适合处理复杂的条件跳转。N8N大学 建议处理大数据集优先用 SplitInBatches。
Q2: 为什么我的 SplitInBatches 只运行了一批就停了？
A: 检查你的输入数据量是否小于你设置的 Batch Size。如果数据总共只有 5 条，Batch Size 设为 10，它自然只会跑一批。
Q3: 这个节点会消耗很多 n8n 的执行次数吗？
A: 会。每一批数据都会消耗一次执行次数。如果你的 workflow 是在 n8n 云服务上运行，且有执行次数限制，请务必谨慎设置 Batch Size。
总结与资源
排查 SplitInBatches 的报错，核心就是死磕三个点：Batch Size 的合理性、Loop On 的准确性、以及 Output 端口的连接。只要这三个地方配置无误，99% 的问题都能解决。
自动化是一个不断试错的过程，遇到报错不要焦虑，把它当作一次深入理解 n8n 机制的机会。希望这篇指南能帮你扫清障碍，让工作流顺畅跑起来。
更多 n8N 硬核教程，欢迎持续关注 N8N大学 (n8ndx.com)。
