n8n错误处理：Error Trigger与Try-Catch怎么选

自动化流程跑起来容易，跑稳却难。n8n 里处理节点报错，最常被拿来对比的两套机制是 Error Trigger Node 和 Try Catch 内联处理。前者是全局兜底，后者是局部急救。选错了，要么告警淹没在噪音里，要么单个节点挂了整条流程陪葬。

两种机制的本质差异

据 YouTube 自动化教程频道的讲解，Error Trigger Node 的作用是捕获整个工作流中任何未被处理的失败，并触发一条专门的错误通知流程。它不关心是哪个节点出的问题，只要工作流以错误状态终止，它就接管后续动作。

Try Catch 内联处理则相反：它把风险节点局部隔离在流程内部，错误一发生就地捕获，并立即尝试降级或回退。它的控制粒度是节点级的，而不是工作流级的。

这个区别决定了它们的使用场景完全不同。全局兜底适合"绝不能让失败悄无声息"的场景，内联处理适合"某个节点可能失败，但失败不该中断整条链路"的场景。

工作流级错误与执行上下文：在 n8n 中，一次工作流执行（Execution）是一个独立的运行实例，每个节点按顺序或分支执行。当某个节点抛出未被捕获的异常时，该执行会以错误状态终止，而 Error Trigger Node 正是监听这种“执行级失败”事件。它本身是一个独立的工作流触发器，当被监控的工作流失败时，n8n 会触发这条错误处理工作流，并传入错误信息（如节点名、错误消息、执行 ID）。因此，Error Trigger 的触发条件是“整个执行失败”，而非某个节点单独报错。理解这一点很关键：如果节点错误被 Try Catch 捕获并处理，执行不会以错误状态终止，Error Trigger 也就不会触发。

用医院急诊和随身急救包来理解

原视频给了一个很贴切的类比：Error Trigger Node 像城市中心医院的急诊室，处理城市任何角落发生的严重事故；Try Catch 则像随身携带的急救包，小伤口当场处理，不必跑一趟医院。

这个类比点出了两者的成本差异。走全局 Error Trigger，意味着工作流已经失败终止，你拿到的是"事后告警"，需要人工或下游流程介入恢复；走内联 Try Catch，流程还活着，可以在同一个执行上下文里继续往下走。

换句话说，Error Trigger 是观测与通知手段，Try Catch 是恢复与容错手段。把观测手段当容错手段用，流程该断还是断；把容错手段当观测手段用，异常会被吞掉，你根本不知道它发生过。

实战中如何搭配

比较稳妥的做法是两层都上。外层配置 Error Trigger Node，负责兜住所有没被局部处理的漏网之鱼，把错误信息推送到通知渠道；内层对已知的高风险节点（比如外部 API 调用、数据格式不稳定的解析节点）加 Try Catch，就地做重试或降级处理。

这样分工的好处是告警噪音会显著下降。可预期的、能自愈的错误在局部被消化掉，全局错误触发器只在真正需要人介入时才响。反过来说，如果所有节点都用 Try Catch 包一遍，流程会变得臃肿且难以维护；如果只用全局触发器，则失去了在流程内优雅恢复的机会。

一个容易被忽略的细节是：局部捕获后要不要重新抛出错误，取决于业务语义。可降级的错误就地消化即可，不可降级的错误应该继续向上抛，交给全局触发器处理，避免错误被静默吞没。

重新抛出（rethrow）的语义：在 Try Catch 结构中，“重新抛出错误”意味着在局部捕获并处理之后，主动将错误再次抛出，使工作流执行以错误状态终止。这样做的目的是让错误继续向上传递，最终由全局 Error Trigger 接管。在 n8n 的 Try Catch 节点中，通常可以通过配置“Throw Error”选项或在 Catch 分支中手动抛出错误来实现。是否重新抛出取决于业务语义：可降级的错误（如缓存未命中、非关键字段缺失）就地消化即可；不可降级的错误（如认证失败、核心数据丢失）应重新抛出，避免被静默吞没。这一机制是分层错误处理的关键衔接点。

选择建议

判断标准可以简化成一句话：这个错误发生时，流程还能不能继续有意义地往下走？ 能，就用 Try Catch 内联处理；不能，就让它失败，交给 Error Trigger 做告警和后续动作。全局安全网保证不漏报，内联处理保证可恢复，两者不是替代关系，而是互补关系。