还在被 API 限流搞崩溃？这可能是你离“优雅自动化”最近的一次
笔者在 N8N大学 社区里潜水时，发现了一个高频痛点：很多同学在处理批量数据时，满怀信心地把几千条数据塞进一个 Loop 循环里，结果跑了不到 100 条，接口就直接返回 429 Too Many Requests，整个工作流瞬间“猝死”。
这感觉就像什么呢？你开着法拉利去加油，结果加油站规定“每秒钟只能加一滴油”。你不仅得停下引擎，还得跟保安大哥求情。对于自动化来说，这种“急停”不仅效率低下，更会丢失宝贵的执行数据。今天，笔者就带大家硬核拆解：如何在 n8n 的 Loop 循环中，通过配合 Wait 节点，精准拿捏 API 的脉搏，实现完美的速率限制（Rate Limit）。
核心逻辑：把“猛冲”变成“呼吸”
在开始实操前，我们得先换个思路。为什么接口会限流？因为服务器怕你把它“冲垮了”。所以，自动化的最高境界不是跑得快，而是跑得稳。
在 n8n 中，Loop 节点（通常是 Loop Over Items）负责源源不断地产生请求，而 Wait 节点则像是一个“刹车片”。我们的目标很简单：每完成一次请求，强制暂停一小段时间。这不仅能绕过限流，还能极大降低服务器压力，让你的 workflow 更加健壮。
实战拆解：三步打造“防限流”工作流
下面，笔者将以一个模拟的场景为例：假设有 1000 个用户 ID，我们需要通过 API 逐个查询信息，且 API 限制每秒最多 2 次请求。
第一步：准备数据与 Loop 循环
首先，你需要一个数据源（比如 Google Sheets 或 Set 节点），里面包含你要处理的列表。
- 拖入一个 Loop Over Items 节点。
- 在 Batch Size（批次大小）中，建议设置为 1。这一点至关重要！我们要的是逐条处理，因为我们要在每一条之间插入延迟。
- Mode 选择 Linear（线性模式）即可。
第二步：插入核心“刹车”——Wait 节点
这是整个工作流的灵魂所在。很多新手会把 Wait 放在 Loop 之后，这是错误的。Wait 必须放在 Loop 内部，紧跟在 API 请求之后。
操作路径：
- 在 Loop Over Items 的输出端，连接你的 HTTP Request 节点（去请求 API）。
- 在 HTTP Request 节点的输出端，拖入一个 Wait 节点。
- 关键参数设置：点击 Wait 节点，在 Wait Amount 中输入延时秒数。如果你的限制是 2次/秒，那么一次请求最快也得 0.5 秒。为了保险起见，我建议设置为 1 秒。
第三步：闭合循环与数据透传
此时，Loop 还没有闭合。你需要将 Wait 节点的输出，直接连回到 Loop Over Items 节点的 Next Item 输入端口（注意是那个小圆点图标，而不是主输入端口）。
逻辑流如下：
流程开始 -> Loop (取出ID: 1) -> HTTP Request (查询ID: 1) -> Wait (暂停1秒) -> Loop (取出ID: 2) -> ...
这样就形成了一个严格的“请求-等待-再请求”的闭环。
避坑指南：那些教科书不会告诉你的细节
虽然逻辑简单，但实操中笔者踩过两个大坑，这里分享给大家：
1. 循环内的“数据丢失”陷阱
当你把 Wait 节点接入 Loop 时，必须确保 Wait 节点能透传 HTTP Request 返回的数据。n8n 默认会透传上一级的数据，但如果你在 Wait 节点里配置了特定参数，可能会导致数据被重置。
解决方案： 保持 Wait 节点的配置尽可能干净，它只需要负责“阻塞时间”，不需要处理数据。最终在 Loop 结束后，你可以通过 Aggregation 节点将分散的数据重新合并。
2. 并发与批量的混淆
有些同学为了追求速度，开启了 HTTP Request 的 Batch Mode（批量模式）或者使用了 Parallel Loop（并行循环），然后又在后面加了个 Wait。
大坑预警： 这样做是没用的！如果你一次发 10 个请求（并发），即使后面 Wait 了 10 秒，服务器也是一瞬间收到了 10 个请求，依然会触发限流。记住：防限流的核心是串行化（Serial）+ 延迟。
进阶方案：应对复杂的“令牌桶”算法
上面的“固定间隔”（每秒 1 次）虽然稳妥，但效率不是最高。有些 API 采用的是“令牌桶”算法，允许短时间内的突发流量。
如果你处理的是这种场景，可以尝试在 n8n 中使用 Code 节点配合 Wait。
思路是：利用 Code 节点记录上一次请求的时间戳，计算出下一次请求需要等待的精确毫秒数，动态调整 Wait 的时间。这稍微硬核一点，适合对速度有极致要求的同学。
FAQ：N8N大学 常见问题解答
Q1: 设置 Wait 会导致我的工作流运行时间变得非常长吗？
A: 确实会增加总耗时，但这是为了稳定性必须付出的代价。如果你有 1000 条数据，每条延迟 1 秒，大约需要 16 分钟。与其让它跑 1 分钟然后报错重头再来，不如稳稳地花 16 分钟跑完。这就是“慢即是快”。
Q2: 除了 Wait 节点，还有其他方法吗？
A: 有的。对于懂代码的同学，可以直接在 HTTP Request 节点的 Onion（选项）中，配合 Code 节点编写自定义逻辑。但对于 90% 的场景，Wait 节点是最直观、最不容易出错的选择。
Q3: 如果 API 明确给出了 Rate Limit 的 Header 信息（如 X-RateLimit-Reset），n8n 能自动识别吗？
A: n8n 原生不支持自动解析 Header 并动态暂停（除非写自定义 JS 代码）。但你可以通过 If 节点判断 HTTP 状态码是否为 429。如果是，进入一个“错误处理分支”，在该分支里先 Wait 一段较长时间（比如 60 秒），然后再重试。
总结与资源
在 n8n 中实现 API 限流保护，本质上是用时间换取空间的策略。Loop + Wait 是最经典、最稳健的组合拳。不要迷信高并发，对于大多数第三方 API 来说，稳稳地“细水长流”才是自动化成功的关键。
如果你想深入了解更多 n8n 的高级技巧，欢迎访问 N8N大学 (n8ndx.com)。我是你的主编，愿你的工作流永远不报红！
