别让 n8n 失联：工作流、错误处理教程

这篇文章解决什么问题？当 n8n 只是帮你发一条测试消息时，它看起来很简单；可一旦流程每天自动跑、会调用外部 API、会写数据、会发通知，真正困难的就不再是“能不能跑通”，而是：失败后谁知道？临时故障要不要再试？重试会不会重复发消息？一条流程越来越长，怎么改才不会牵一发而动全身？这篇教程会带你把一条“能跑”的 n8n 工作流，升级成一条可拆分、可报警、可重试、可追踪的可靠工作流。

你可以把 n8n 想成一间开始接真实订单的小型工作室。最开始，一个人从头做到尾没有问题；但当订单多了、步骤多了、外部服务偶尔不稳定时，把所有事塞进一个人手里，只会越来越乱。成熟的做法是：把重复工作交给专门小组；出问题时有报警台；遇到短暂故障时按规则重试；真正不能继续时留下完整现场，而不是静悄悄地失败。

n8n 官方把这种思路分别放在子工作流、错误工作流与节点设置中。子工作流由 Execute Sub-workflow 与 Execute Sub-workflow Trigger 协作，让一个工作流调用另一个工作流；错误工作流则由 Error Trigger 启动，可在某条工作流执行失败时接收错误信息并发出通知。[1] [2] [3]

先分清四件事：重试、继续、报警和恢复不是一回事

刚开始接触错误处理时，很容易把所有“出错后的动作”叫作重试。但这四件事分别解决不同问题：重试是同一件事再试一次；继续是承认这一步失败后，流程仍往下走；报警是把失败告诉人；恢复是根据保存的现场重新执行或人工处理。

这篇文章的核心原则只有一句：

把短暂问题交给重试，把可预期的坏数据交给分支，把系统性失败交给错误工作流，把已经产生副作用的任务交给可追踪的恢复机制。

为什么“一个超级长流程”会越来越难维护？

假设你有一条每日新闻工作流：定时启动 → 抓 5 个来源 → 去重 → AI 摘要 → 发送 Telegram → 写入 Notion。刚开始它可能只有十几个节点，完全能看懂。可后来你又加了关键词过滤、翻译、不同主题发送到不同频道、失败后重试、月底汇总……画布很快就像一盘缠在一起的耳机线。

这时不要急着重写。先把重复且独立的步骤找出来，例如“把一批文章清洗成统一字段”“把内容生成固定格式的日报”“向某个渠道投递结果”。这些就是适合抽成子工作流的部分。

第一部分：子工作流——把一条大流程拆成可复用的小工具

1. 什么是子工作流？

子工作流可以理解成工作室里的“专业小组”。主工作流负责接订单、安排顺序；子工作流只专注完成一件可重复的事，例如“清洗文章数据”“生成日报”“写入 Notion”。主工作流把资料交给它，等它完成后再拿回结果继续往下走。

n8n 官方说明，子工作流的好处是把流程拆成模块化、类似微服务的组件；当流程变大甚至遇到内存压力时，也可以通过拆分降低单条流程的复杂度。[1]

2. 什么时候值得拆？什么时候不要拆？

不要为了“高级”而拆。一个只执行一次、没有重复逻辑的三节点流程，硬拆成四个子工作流，只会增加理解成本。适合拆分的信号通常是：同一段逻辑会被两条以上流程使用；某一段包含很多节点、需要独立测试；你希望它有清楚的输入与输出；或者它属于“高风险步骤”，需要单独看执行记录。

3. 实战：创建第一个“内容清洗子工作流”

我们先做一个最容易理解的子工作流：无论资料来自 RSS、HTTP Request 还是表单，它都接收 title、url、publishedAt、source，并返回一份结构统一、可供 AI 或通知节点继续使用的内容。

第一步：新建工作流。给它命名为：子工作流｜内容清洗与统一字段。命名建议采用“类型｜职责”的格式，后面多了以后你一眼就知道它不是直接给用户运行的主流程。

第二步：添加触发器。搜索并添加 Execute Sub-workflow Trigger。在部分界面中，它显示为 When Executed by Another Workflow。它必须是子工作流的第一个节点，表示“只有其他工作流调用我时，我才开始”。[3]

第三步：定义输入。在 Input data mode 中，初学时推荐选择 Define using fields below。然后建立四个字段：

这一步像给前台一张“收件标准”：以后任何主工作流要调用你，至少要把标题和链接交齐。n8n 也支持用 JSON 示例定义输入，或者选择 Accept all data；但完全接收所有数据意味着子工作流自己要承担字段缺失和格式不一致的风险。[1]

第四步：添加 Edit Fields。把标题去掉多余空格、统一字段名，并加入一个固定的 processedAt。例如可以新增：

cleanTitle     = {{ $json.title.trim() }}
cleanUrl       = {{ $json.url }}
source         = {{ $json.source || '未知来源' }}
processedAt    = {{ $now.toISO() }}

这里不要害怕表达式。它只是告诉 n8n：“从这条资料里取出标题，再去掉前后空格。”如果某个字段可能不存在，可以给它一个默认值；这会让后续节点少一些意外。

第五步：保存，不要用 Manual Trigger 测试。子工作流不会像普通流程那样由你手动启动。它需要由主流程调用。官方还提醒：子工作流本身存在错误时，父工作流无法触发它，所以先确认每个节点没有红色配置错误。[1]

4. 在主工作流里调用子工作流

回到你的主工作流。在资料获取与后续处理之间，添加 Execute Sub-workflow 节点。

按下面配置：

1. Source 选择 Database；
2. 选择 From list，从列表中选刚创建的 子工作流｜内容清洗与统一字段；
3. 你会看到刚才定义的输入字段自动出现；
4. 将主流程的数据映射进去，例如 title 填 {{ $json.title }}，url 填 {{ $json.link }}；
5. 保持 Wait for Sub-Workflow Completion 开启。

为什么建议初学阶段打开等待？因为主流程必须先拿到清洗后的字段，才能继续做判断、AI 摘要或发送。关闭等待更像“把任务交出去就继续忙别的”，适合不需要立即拿回结果的后台任务，例如把日志异步写入归档库。Execute Sub-workflow 支持“全部数据只调用一次”与“每条数据分别调用一次”两种模式；前者适合一批资料整体处理，后者适合每篇文章都要独立处理。[2]

子工作流最后一个节点的输出，会回到父工作流的 Execute Sub-workflow 节点。你可以把它想成专业小组交回的一份整理好的文件夹。

新手避坑：不要让子工作流 A 调用 B、B 又调用 A。这会形成循环调用，既难排查，也可能消耗大量资源。子工作流应该像工具箱：职责单一、输入清楚、输出清楚。

第二部分：错误工作流——让失败不再悄无声息

一条工作流失败并不一定代表你配置错了。外部 API 会临时超时，网络会断，第三方服务会限流，某个凭据会过期。真正危险的不是失败，而是失败后你完全不知道。

n8n 提供了专门的 Error Trigger。当一条绑定了错误工作流的自动化流程失败时，Error Trigger 可以收到工作流名称、失败节点、错误信息、执行 ID、执行链接等上下文，然后由你决定通知谁、记录到哪里。[2] [4]

1. 创建一个全站通用的错误报警工作流

新建一条工作流，命名为：系统｜工作流错误报警。第一节点添加 Error Trigger。它不需要传统触发器，也通常不需要发布。官方说明，Error Trigger 只能在自动运行的工作流失败时触发；你手动点击 Execute Workflow 造成的失败，不能用它来完整测试。[3]

Error Trigger 传入的信息大致包含这些字段：

{
  "execution": {
    "id": "执行编号",
    "url": "执行详情链接",
    "error": {
      "message": "错误摘要"
    },
    "lastNodeExecuted": "最后执行的节点"
  },
  "workflow": {
    "name": "发生失败的工作流名称"
  }
}

接着加一个 Edit Fields，把报警内容整理成真正适合人阅读的文本：

标题：🚨 n8n 工作流执行失败
工作流：{{ $json.workflow.name }}
失败节点：{{ $json.execution.lastNodeExecuted || '触发阶段或未知节点' }}
错误：{{ $json.execution.error.message || $json.trigger.error.message }}
执行详情：{{ $json.execution.url || '本次没有生成可打开的执行链接' }}

注意：如果失败发生在主流程的触发器阶段，执行记录可能还没生成，因此 execution.id 或 execution.url 不一定存在。n8n 官方文档明确说明了这类触发阶段错误会提供不同结构的数据。[2]

最后接一个 Telegram、Gmail、Discord 或企业微信通知节点。初期建议先发到你最常看的 Telegram；不要只发邮件，因为凌晨失败时邮件很容易被忽略。

2. 把错误工作流绑定给主流程

回到需要保护的主工作流，点击右上角 Options → Settings，在 Error workflow 下拉框中选择 系统｜工作流错误报警，保存即可。你可以把同一个错误工作流绑定给多个主流程；这就像让所有部门共用一个值班报警台。[2]

3. Stop And Error：什么时候应该主动喊停？

有时流程没有发生“技术报错”，但业务上已经不能继续。例如抓到的新闻没有标题；某个订单没有用户 ID；AI 返回空内容；接口返回成功但字段不完整。这种情况下，继续往下发消息比失败更糟。

这时可以在 If 节点的异常分支后放置 Stop And Error 节点，写出一条人能看懂的原因：

未找到必需字段 title，停止发送日报，避免空内容覆盖原记录。

这样 n8n 会把本次执行标记为失败，并触发你的 Error Trigger 工作流。官方也建议用 Stop And Error 在你定义的条件下主动使执行失败，从而交给错误工作流统一处理。[2]

第三部分：重试机制——把“偶尔不通”与“永远做错”分开

重试最适合处理临时性故障。例如 API 短暂 502、网络连接超时、第三方服务暂时限流。它不适合处理缺少凭据、字段写错、URL 填错、权限被永久拒绝这些确定性问题。对后者重试十次，只会让你等更久、还可能触发更严重的限流。

1. 节点级重试怎么开？

以 HTTP Request 节点为例，点击节点后切换到 Settings 标签页，找到类似 Retry On Fail 的选项。不同 n8n 版本文案可能略有不同，但核心配置通常包括：是否失败后重试、最多尝试次数、两次之间等待多久。

对大多数普通 API，一个保守起点可以是：

这里的“3 次”不是硬规则。如果你调用的是可能需要较长恢复时间的服务，可以适当延长等待；如果你调用的是有严格限流的服务，应减少频率，并优先查看服务方是否返回了 Retry-After 之类的提示。

2. 为什么不能无限重试？

想象你给一家已经关门的店铺打电话：重拨两三次合理；一分钟打 300 次既不会让店开门，还可能被对方拉黑。无限重试会消耗 n8n 执行资源、放大第三方 API 压力，也可能让同一条数据被处理多次。

建议把重试理解为“给临时故障一个缓冲”，而不是“总有一次会成功”。当三次仍失败时，应交给错误工作流报警，由你检查凭据、接口状态、字段或业务规则。

3. Continue On Fail 应该怎么用？

Continue On Fail 的意义是：这个节点出错时，不让整条工作流立刻停止，而是带着错误结果继续往下走。它适合“本批 50 条新闻里，坏掉 1 条也不影响剩下 49 条”的场景；不适合“付款成功后必须写入订单表”这种关键步骤。

正确的用法不是“打开后就不管”，而是：打开后立即接一个 If 节点，检查本条数据是否带有错误信息；成功的进入正常路径，失败的进入记录/通知路径。这样你既不因为一条坏数据让全批停摆，也不会默默丢掉失败信息。

第四部分：重试以后，怎样避免重复发送和重复写入？

这是可靠工作流最容易被忽略的一步。比如 HTTP Request 已经成功把一条日报发到 Telegram，但 n8n 在记录执行状态前网络断了；你重试时，它可能再次发同一条日报。又比如 Notion 已经新增了一页，后续节点失败；从头重跑又会新增第二页。

这类问题叫“副作用重复”。你不需要先背这个术语，但要记住：只要一个节点会向外部世界写入东西、发出东西、扣费或改变状态，重试前就要想办法证明它还没有做过。

1. 最简单的防重复方法：给每条数据一个唯一钥匙

例如新闻可以用原文 URL；订单可以用订单号；语音笔记可以用音频文件 ID；每日简报可以用 日期 + 分类。在写入 Notion、Google Sheets 或数据库之前，先用这个唯一钥匙查询是否已经存在；存在就跳过，不存在才创建。

唯一键示例：
{{ $json.url }}

每日简报唯一键示例：
{{ $now.toFormat('yyyy-LL-dd') }}-科技日报

如果你的目的地支持唯一字段或 upsert（有则更新、无则创建），优先使用它。若没有，就先查询、再用 If 判断、最后创建。多一个查询步骤，看起来麻烦，却能帮你避免“重试后发三遍”的尴尬。

2. 把“已完成标记”放在最后一步

不要在流程刚开始就写“已处理”。正确顺序应该是：取数据 → 处理 → 发送/写入成功 → 最后写入已完成标记。如果你太早标记，后面失败后系统会以为它做完了；如果太晚又没有唯一键，重试可能重复做。因此最稳的方式是“唯一键检查 + 成功后标记”同时使用。

第五部分：把所有控制组合起来——一条可靠日报流程长什么样？

现在把子工作流、错误工作流、重试与防重复放在一起。下面是一条“每日资讯简报”的推荐结构：

Schedule Trigger
  → Execute Sub-workflow（抓取与统一字段）
  → Remove Duplicates
  → If（是否存在有效内容）
      ├─ 否 → 结束 / 记录“今日无新增”
      └─ 是 → Execute Sub-workflow（生成日报）
              → 查询唯一键（今天是否已经发过）
              → If
                  ├─ 已发送 → 跳过
                  └─ 未发送 → Telegram / Gmail
                                  → 写入完成标记

任意关键节点失败
  → Error Trigger 工作流
  → 整理错误信息
  → Telegram 报警 + 记录执行链接

这里有三个关键设计。第一，抓取与日报生成拆成了子工作流，因此换来源、换频道、换通知方式时，不需要反复复制核心逻辑。第二，外部 API 和通知节点开启有限重试，临时故障有机会自行恢复。第三，发送前检查唯一键、发送后写完成标记，即使你后来在 Executions 页面重新执行，也不会轻易造成重复投递。

一套真正能落地的测试方法

不要一次性发布整条复杂流程。按下面顺序测试，成功率最高：

要特别注意：Error Trigger 不能通过手动运行主工作流来完整测试。应使用自动触发方式，例如临时开启一个 Schedule Trigger，等它实际执行失败后，再观察错误工作流是否收到信息。[3]

常见问题：看起来“高级”的设置，为什么反而把流程弄坏了？

问题一：子工作流没有返回数据

先检查子工作流的最后一个节点是否真的输出了数据。父工作流会接收子工作流最后一个节点的输出；如果最后一站没有项目、被 If 分支挡住，父流程自然没有东西可继续处理。[1]

问题二：错误报警工作流没有触发

先确认主工作流的 Settings → Error workflow 是否真的选择了报警工作流；再确认报警工作流第一个节点是 Error Trigger；最后确认主流程是自动触发失败，而不是你手动点执行后失败。[2] [3]

问题三：重试开了，为什么还是失败？

重试只能解决暂时性问题。检查错误内容：若是 401 或 403，多半是凭据或权限；若是 404，多半是地址或资源不存在；若字段找不到，通常是上游数据结构变了。把它们交给错误报警，而不是继续增加重试次数。

问题四：流程没报错，但结果少了一部分

重点看是否启用了 Continue On Fail。它会让流程继续，但你必须为错误数据建立显式分支、记录和通知。否则这不是“稳定”，只是“安静地漏掉了数据”。

问题五：重跑执行后重复发消息

在所有会产生外部副作用的节点前增加唯一键检查。对“每日日报”这类任务，至少用日期 + 分类做一次检查；对“每篇文章”这类任务，用原始 URL 或内容 ID 做检查。

最后的可靠运行清单

当你准备让一条工作流长期运行时，用这张表做最后检查：

可靠的自动化并不是“永远不出错”。更现实的标准是：它出错时能有限次自救；自救不了时能第一时间告诉你；你回来后能看清哪里坏了；重新执行时不会把已经做过的事再做一遍。掌握子工作流、错误工作流和重试机制后，你的 n8n 才真正从一张能跑的画布，变成一套可以长期交给它值班的系统。

参考来源

1. n8n 官方文档：Break workflows into smaller parts —— 子工作流创建、输入模式、父子工作流数据传递与调试入口。
2. n8n 官方文档：Handle errors gracefully —— 错误工作流的绑定、Error Trigger 传入数据、Stop And Error 的使用。
3. n8n 官方文档：Error Trigger —— 错误触发器的限制、自动执行失败的触发方式与错误数据结构。
4. n8n 官方文档：Execute Sub-workflow —— 子工作流调用来源、输入字段、批处理模式和等待完成选项。
5. n8n 官方文档：Execute Sub-workflow Trigger —— 子工作流触发器与可复用工作流设计。