还在为 Loop Over Items 的报错抓狂？一条数据失败导致全盘皆输？
兄弟们，我是 N8N大学 的主编。今天咱们来硬核拆解一个新手最容易踩、也是老手最容易忽视的坑。
你有没有遇到过这样的场景：你需要批量处理 1000 条数据，用 Loop Over Items 循环执行。结果跑到第 50 条时，因为数据格式不对或者接口超时，整个 Workflow 直接炸红报错，剩下的 950 条数据直接“陪葬”。
这种“一损俱损”的体验非常糟糕。在生产环境中，我们绝对不允许因为单条数据的脏乱差，导致整个批处理任务中断。今天，笔者就带你用最硬核的手段，彻底解决这个问题，让你的 Loop 拥有“打不死的小强”精神。
为什么会“全盘皆输”？理解 n8n 的默认机制
先得弄明白“敌人”是怎么运作的，才能精准打击。
在 n8n 中，默认的错误处理机制是“阻塞式”的。当 Loop Over Items 内部的节点（比如 HTTP Request）抛出异常（如 404, 500, 或者 JSON 解析失败），n8n 会认为这个 Workflow 遇到了致命错误。
此时，n8n 会立即停止执行后续节点，并将整个 Workflow 标记为 Failed。更糟糕的是，它不会保存已经处理成功的数据，也不会继续处理剩下的数据。这就是典型的“一颗老鼠屎坏了一锅粥”。
核心方案：利用 If 节点实现“错误捕获”
要在循环中实现“报错继续”，核心逻辑不是让 n8n 忽略错误，而是要**主动捕捉错误**，并将其转化为一种“正常的数据流”来处理。
我们需要利用 If 节点的“黑魔法”。具体操作如下：
- 不要直接连接： 你的核心业务逻辑（比如 HTTP Request）不要直接连向下一个节点。
- 设置成功路径： 从 HTTP Request 的
Output连出一条线到处理成功数据的节点。 - 设置失败路径： 这是关键。从 HTTP Request 的
Output连出第二条线到一个 If 节点。
在 If 节点中，我们配置条件：Execution Data -> Status Code -> is not equal to 200（或者根据你的业务判断 error 字段）。这样，只有当报错发生时，才会走这条“错误处理通道”。
实操拆解：3 步打造“不死循环”
下面，笔者手把手教你搭建这个容错流程。假设你的流程是：获取列表 -> 循环 -> 写入数据库/发邮件。
步骤 1：正常的数据处理分支
在 Loop 内部，你的主逻辑保持不变。例如，Loop Over Items -> HTTP Request。如果请求成功（200 OK），直接连接到你的下一步操作，比如 Set 节点（标记为“成功”），最后流出循环。
这保证了正常数据的快速通过。
步骤 2：构建“错误缓冲区”
这是核心。从 HTTP Request 节点拉出一条线到 If 节点。配置逻辑如下：
- 条件：
Node Execution Data -> Status Code -> is not equal to 200(或者Response Body -> contains -> error)。 - 一旦满足条件（即报错），说明这条数据“坏”了。
此时，n8n 不会中断，而是进入了这个 If 节点的“True”分支。在这条分支上，我们通常接一个 Set 节点，专门用来记录错误信息。比如设置字段 status: "failed"，error_message: "具体的错误信息"。
步骤 3：合并与记录
处理完成功数据和失败数据后，我们需要将它们“收拢”。在 Loop 内部，将“成功分支”和“错误分支”都连接到同一个 Set 或 Aggregate 节点（或者直接流出 Loop）。
重点来了：当所有循环跑完，流出 Loop Over Items 后，建议接一个 Spreadsheet File 节点或者 Email 节点，生成一份“处理报告”。
这样，你就拿到了一份清晰的报表：哪些成功了，哪些失败了，为什么失败。老板看了都得给你点赞。
避坑指南：实战中容易忽略的细节
虽然逻辑通了，但实操中还有两个坑，N8N大学 必须提醒大家：
1. 隐形的 200
有些 API 会返回 200，但在 Body 里塞错误信息（比如 {"code": 500, "msg": "系统异常"}）。这种情况下，单纯判断 HTTP 状态码是没用的。你必须在 If 节点里深入解析 JSON Body，例如：JSON Body -> code -> is not equal to 0。
2. 异常节点的“吞并”能力
如果你觉得手动配置 If 节点太麻烦，n8n 有一个原生节点叫 Continue On Fail（在旧版或特定配置中），或者你可以直接利用 HTTP Request 自带的 Continue On Fail 设置（在节点的 Settings 里）。勾选它后，任务不会中断，而是将错误信息作为输出数据流向下传递。这是个“大杀器”，但新手容易找不到，因为它藏在节点的 Settings（齿轮图标）里，而不是主界面。
FAQ：你可能还想问
Q1: 如果我使用了“Continue On Fail”，还需要 If 节点吗？
A: 如果只是为了不中断执行，勾选 Settings 里的 Continue On Fail 就够了。但如果你需要对“成功”和“失败”的数据进行不同的逻辑处理（比如成功的写入 A 库，失败的发邮件报警），那就必须配合 If 节点来分流。
Q2: Loop Over Items 会不会因为数据量太大导致内存溢出？
A: 会。如果循环次数成千上万，建议使用 Batch（批处理）模式，或者将数据分片。但在处理报错这个场景下，只要单条数据处理逻辑不占用过大内存，上述容错方案是完全胜任的。
Q3: 有没有更简单的“全局”设置？
A: 目前 n8n 的设计哲学是“显式优于隐式”。虽然你可以在 Workflow 的 Settings 里设置 "Error Workflow" 来捕获整个流程的错误，但在 Loop 内部处理单条报错，推荐使用上述的 If 节点法，因为它更灵活，能保留上下文数据。
总结与资源
在 n8n 的自动化世界里，健壮性（Robustness）比跑通更重要。学会在 Loop 中处理单条报错，意味着你的自动化流程从“演示级”升级到了“生产级”。
记住 N8N大学 的核心理念：**让机器处理异常，让人只看结果。**
如果你在实操中遇到了具体的报错信息，欢迎在 N8N大学 社区留言，笔者会亲自帮你排查。
