作为 N8N大学 (n8ndx.com) 的首席主编，笔者见过太多新手在刚接触 n8n 自动化时，因为一个看似简单的操作——批量调用 API——而惨遭“封号”。那种满怀期待搭建好流程，结果第二天发现账号被封、数据全丢的痛苦，我非常理解。
今天，我们就来硬核拆解 n8n 中最常用的限流神器：**SplitInBatches** 节点。如果你正准备批量导出数据、发送营销邮件，或者同步 CRM 客户列表，请务必看完这篇避坑指南。
为什么你的 API 总被封？先搞懂“限速”的底层逻辑
大多数 API 服务（如 OpenAI、微信公众号、SendGrid）都有严格的速率限制（Rate Limiting）。它们通常按“每分钟请求数”或“每秒请求数”来计算。
如果你在 n8n 中直接给一个数组循环发送 HTTP 请求，n8n 的执行速度极快，可能 1 秒内就能发出 100 个请求。这对 API 服务器来说就是一次“流量攻击”，触发风控是必然的。**SplitInBatches 节点的作用，就是把这 100 个请求拆分成小批量，人为制造“延迟”，模拟正常人的操作频率。**
核心实操：SplitInBatches 节点配置详解
在 N8N大学 的实战案例中，我们通常会遵循以下三个步骤来配置。请打开你的 n8n 编辑器，跟着操作。
步骤 1：准备数据与循环结构
首先，你需要一个数据源。通常是一个 Set 节点（用于模拟数据）或者是一个 Cron 节点（定时触发）。假设我们有一组包含 100 个联系人的列表（Items）。
将这个数据流直接连接到 SplitInBatches 节点。注意：此时不要让数据直接流向 HTTP 节点，否则就是“自杀式”攻击。
步骤 2：配置 Batch Size（批处理大小）
选中 SplitInBatches 节点，在参数面板中，最关键的设置是 Batch Size。
笔者建议：对于大多数 API，初始值不要超过 10。如果你的目标 API 限制为 60次/分钟，那么 Batch Size 设为 5-10 是比较安全的。这意味着 n8n 会一次性处理 5 条数据，然后等待。
步骤 3：设置间隔时间（关键！）
SplitInBatches 有一个参数叫 Wait Time (ms)（等待时间，毫秒）。
这是防止被封禁的核心参数。它定义了每批数据处理完后，n8n 需要暂停多久再处理下一批。
- 如果你的 API 限制是 60次/分钟：你应该设置
Batch Size = 1，Wait Time = 1100（1.1秒）。这样每秒最多 1 个请求。 - 如果你的 API 限制是 1000次/秒：你可以设置
Batch Size = 10，Wait Time = 10。
实战技巧：永远给 API 预留一点缓冲空间。如果 API 限制 60次/分，按 50次/分去设限速，留出 15% 的余量应对网络波动。
步骤 4：连接 HTTP Request 节点
从 SplitInBatches 节点的输出端（Output）拉出一条线，连接到你的 HTTP Request 节点。在 HTTP Request 节点中配置好 URL、Method 和 Body。
此时，数据流会变成这样：
数据源 -> SplitInBatches -> HTTP Request -> SplitInBatches (循环返回)
当第一批数据处理完后，SplitInBatches 会自动将剩余数据送回 HTTP Request，直到所有数据处理完毕。
避坑指南：实战中容易报错的细节
在 N8N大学 的学员反馈中，以下两个错误最常出现：
1. 无限循环陷阱
如果你错误地将 SplitInBatches 的“重新开始”输出端（Output）连接回了自己，或者连接到了上游节点，会导致死循环。请务必确保：SplitInBatches 的输出仅连接到下游的业务节点（如 HTTP Request）。
2. 忽略了 API 的突发限制（Burst Limit）
有些 API 限制比较复杂，例如“每秒 2 次，但允许突发 10 次”。如果你把 Batch Size 设置得过大（比如一次性发 20 个请求），即便你设置了 1 秒的等待时间，第一批请求就会直接触发 API 的突发限制导致封禁。
解决方案：阅读 API 官方文档，将 Batch Size 设置得小于突发限制的阈值。
进阶技巧：让限速更智能
如果你需要更精细的控制，可以结合 Wait 节点使用。
有时候 API 返回的报错信息是 429 Too Many Requests。你可以利用 n8n 的错误处理流程（Error Trigger）：当捕获到 429 错误时，触发一个 Wait 节点等待更长的时间（例如 5 秒），然后再重试。这比死板地设置固定间隔要灵活得多。
FAQ：常见问题解答
Q1: SplitInBatches 和 n8n 的全局并发设置有什么区别？
A: SplitInBatches 是在单个 Workflow（工作流）内部控制数据流的节奏；而全局并发设置（通常在 n8n 环境变量或企业版设置中）是控制整个 n8n 实例同时运行的任务数。对于 API 限速，SplitInBatches 是更直接、更可控的选择。
Q2: 我的 API 限制是“每天 10000 次”，该怎么设置？
A: 这种情况属于总量控制，而非瞬时速度。你需要计算一天的秒数（86400秒），然后分配 10000 次请求。但通常更推荐按小时或分钟来分割任务。例如，你可以设置每小时处理 500 次，这可以通过 Cron 节点配合 SplitInBatches 来实现。
Q3: 设置了 Wait Time 但还是被封了，为什么？
A: 检查你的数据是否在多个节点并行处理。确保你的流程是线性的（Linear）。另外，确认你计算的 Wait Time 是否包含了 HTTP Request 节点本身的执行时间。如果网络延迟很高，实际请求间隔可能比你设置的更短。
总结与资源
在 n8n 自动化中，速度与稳定性往往需要权衡。SplitInBatches 节点是平衡这两者的利器。记住这句话：**宁可慢一点，也不要让 API 看到你像机器一样的请求速度。**
更多 n8n 硬核实战教程，请持续关注 N8N大学 (n8ndx.com)。如果你在配置过程中遇到具体报错，欢迎加入我们的社区交流。
