引言

到本课程的此阶段,你已经掌握了 IF 和 Switch 节点的分支用法、用 item 拆分和批处理实现的循环、合并并行分支,以及对高风险操作包裹错误处理。本节课的最后一课,是把所有这些内容整合到同一个工作流中,体现真实生产自动化是如何构建的。

目标不是引入新的节点。目标在于展示这些模式如何组合——循环如何接入合并、错误处理如何包裹循环、分支逻辑如何决定合并后的结果走向下一步。你在这里构建的工作流,是一个可以适配到你自己场景的实用模板。

场景如下:一个工作流,从一个外部 API 读取联系人列表,通过调用第二个 API 对每位联系人进行信息补充,优雅地处理失败,将结果合并,并通过邮件发送汇总报告。

阶段 1:获取并拆分输入数据

工作流以一个每日早晨触发的定时触发节点开始。第一个 HTTP Request 节点调用你的联系人 API,返回一个联系人对象数组。由于 n8n 默认会把结果包裹成单个 item,你需要在循环之前先拆分这个数组。

使用一个 Code 节点把数组拆成独立的 item,以便工作流后续节点可以逐个处理:

return $input.first().json.contacts.map(contact => ({ json: contact }));

这是基础。此后的每一个下游节点都会一次接收一个联系人,这意味着使用 SplitInBatches 的循环式处理,或直接的逐项 HTTP 调用都可以正确工作。

阶段 2:为每位联系人补充信息,并加入错误处理

信息补充步骤会针对每位联系人调用一个第三方 API。第三方 API总会出各种问题——限流、超时、返回结构异常。在生产环境中,必须用 Try/Catch 模式包裹这个调用。

把你的 HTTP Request 节点(信息补充调用)连接到一个作用域限定在该节点的 Error Trigger。成功路径把补充后的数据合并到 item 上。错误路径则补上一个兜底结构,这样 item 就绝不会被静默丢弃:

// On the error branch — Code node that normalizes the failed item
return [{
  json: {
    ...($input.first().json),
    enriched: false,
    enrichmentError: $input.first().json.error?.message ?? 'Unknown error'
  }
}];

成功路径与错误路径必须产出顶层结构相同的 item。这对接下来的合并步骤至关重要——如果某一条分支返回的字段键与其他分支不一致,下游节点就会变得脆弱易坏。

阶段 3:合并并汇总结果

在信息补充步骤(成功和错误两个分支)之后,一个使用 Append 模式的 Merge 节点会把所有 item 重新收集回一条流。然后由一个 Code 节点把结果聚合成一个汇总对象:

const items = $input.all();
const total = items.length;
const succeeded = items.filter(i => i.json.enriched !== false).length;
const failed = items.filter(i => i.json.enriched === false).length;

return [{
  json: {
    total,
    succeeded,
    failed,
    failureRate: (failed / total * 100).toFixed(1) + '%',
    items: items.map(i => i.json)
  }
}];

这个聚合节点是逐项处理和工作流级逻辑之间的分界线。在它之前的所有节点都在操作单条联系人;在它之后的所有节点都在操作整批数据。

阶段 4:按结果分支

不是每次运行都应该发出同样的通知。0% 的失败率配一封简洁的成功邮件。100% 的失败率则应立即告警到人。部分失败则介于两者之间。

使用 IF 或 Switch 节点,按失败率进行路由:

// Switch node — Expression for routing
{{ $json.failed === 0 ? 'success' : $json.succeeded === 0 ? 'critical' : 'partial' }}

每一条分支再连接到不同的通知节点——成功与部分用邮件,严重情况用 Slack 或 PagerDuty。这正是早前课程里学的分支与合并派上用场的地方:你专门构造一个干净的单 item汇总结果,正是为了让这个 Switch 节点能基于简单的值进行判断。

阶段 5:发送报告

每一条通知分支各自格式化自己的消息。成功分支发送一封简短的确认。部分分支附带失败联系人列表,以便相关人员调查。严重分支则触发一条带完整错误详情的紧急告警。

部分分支上的邮件节点使用表达式动态拼接正文:

// Code node before the email — builds the failure list
const failures = $json.items
  .filter(i => i.enriched === false)
  .map(i => `${i.email}: ${i.enrichmentError}`)
  .join('\n');

return [{ json: { ...$json, failureList: failures } }];

到这里工作流就完整了。它包含触发器、带错误处理的逐项处理、结果合并、基于结果的分支,以及定向通知。

小结

一个可投入生产的工作流,不是那种把理想路径处理得很漂亮的工作流,而是那种在失败时不丢数据、分支时不复制逻辑、能自我报告健康状况的工作流。你在本课中应用的这些模式——先拆分再循环、对错误分支做归一化、先聚合再分支、按结果路由——几乎可以成为你在 n8n 中构建的任何自动化的可复用基础模块。把这个工作流当作参考模板,再根据你自己的数据源、API 和通知渠道去适配各个阶段。