工作流跑着跑着就“崩”了？这才是 n8n 自动化的真实面貌
笔者在 N8N大学 带过无数学员，见过太多这样的场景：工作流在本地跑得好好的，一上线就因为某个 API 报错而全线瘫痪。最要命的是，很多同学根本不知道出错了，直到数据对不上才发现问题。
这就是自动化最残酷的真相：**没有错误处理的工作流，就像没有安全带的赛车，看着快，实则是在玩命。**
今天，我们就来硬核拆解 n8n 的错误处理与重试机制。这不是枯燥的理论，而是笔者 8 年踩坑总结出的生存指南。看完这篇，你的工作流稳定性将提升一个维度。
为什么你的工作流总是“莫名其妙”挂掉？
在深入技术细节前，我们先搞清楚敌人是谁。n8n 工作流失败，通常逃不出这三类原因：
- 网络抖动与超时：第三方 API 响应慢，或者干脆断连。
- API 限制与限流：比如微信、钉钉、Slack 等平台的频率限制。
- 数据格式异常：上游传来的数据结构变了，导致节点解析失败。
如果没有配置错误处理，n8n 默认的策略往往是“直接停止”。这意味着你可能丢失正在处理的数据，甚至导致后续流程出现脏数据。
第一道防线：节点级的错误处理选项
很多人只知道 n8n 有个 Continue On Fail（失败时继续），但不知道它到底怎么用。这是最基础的，也是最容易被忽视的。
当你在节点设置中勾选 Continue On Fail 时，如果该节点报错，n8n 不会停止工作流，而是把错误信息作为输出数据传给下一个节点。
实战场景： 假设你有一个 HTTP Request 节点调用天气 API，如果 API 挂了，你可以在下一个节点用 If 节点判断输出中是否包含 error 字段，从而决定是跳过还是发送报警。
核心武器：n8n 的重试机制（Retry）
网络是不可靠的，这是互联网的铁律。对于偶发的网络波动，最有效的手段就是“重试”。n8n 的重试机制非常强大，但配置需要技巧。
在节点的 Settings 中，你可以找到 Retry On Fail 选项。开启后，你需要设置两个关键参数：
- 等待时间 (Wait Time)：建议从 1 秒开始，根据 API 的响应速度调整。
- 重试次数 (Max Retries)：通常设置为 3 次。太多会阻塞队列，太少解决不了问题。
笔者的硬核建议： 不要对所有节点都开启重试。对于写入数据库、扣款等“幂等性”差的操作，重试前务必做好数据校验，避免重复操作导致数据混乱。
进阶玩法：使用 Rework 区处理失败任务
如果你只是想让失败的任务“重试”，n8n 提供了更优雅的方案——Rework 区。
在工作流画布的右上角，你可以看到 On Error 选项。点击进入，你可以设计一个完全独立的错误处理子流程。
操作步骤：
- 开启 On Error 模式。
- 在弹出的错误处理路径中，添加 Send Email 或 Slack 节点，通知管理员。
- 添加 Wait 节点，等待一段时间（如 5 分钟）。
- 最后连接一个 Set 节点，尝试重新封装数据并流回主流程。
这种方式比简单的“重试”更灵活，因为它允许你根据错误类型采取不同的补救措施。
实战案例：API 限流导致的 429 错误
这是一个非常典型的场景。假设你使用 Discord 节点发送消息，Discord 限制每分钟最多发送 3 条。如果你的流程跑得太快，就会触发 429 Too Many Requests。
解决方案：
不要依赖 n8n 的默认重试，因为默认重试往往太快。我们需要手动控制节奏。
在 Discord 节点前，插入一个 Wait 节点。设置等待时间为 20 秒（即 60秒/3次）。这样，无论你的上游数据多快，都会强制降速，从源头避免 429 错误。
如果在 Discord 节点中仍然报错，开启 Retry On Fail，并将等待时间设置得更长，比如 60 秒，作为兜底策略。
避坑指南：时区与数据格式的隐形杀手
错误处理不仅仅是重试，更重要的是预防。笔者见过最冤枉的错误，是因为时区不一致。
如果你的 n8n 安装在 Docker 中，默认时区可能是 UTC。如果你的业务逻辑依赖本地时间（比如“每天上午 9 点执行”），就会出现偏差。
解决办法： 在 Docker Compose 或启动命令中，添加环境变量 TZ=Asia/Shanghai。这能解决 90% 的时间逻辑错误。
另一个坑是数据格式。上游节点输出了空数组，下游的 Spreadsheet File 节点就会报错崩溃。养成在关键节点前使用 If 节点判断 {{ $json.length }} > 0 的习惯，这是职业选手的肌肉记忆。
FAQ：n8n 错误处理常见问题
Q1：重试机制会增加我的 API 费用吗？
A：会的。每次重试都是一次 API 调用。所以重试次数要设置合理，通常 3 次足矣。对于昂贵的 API，建议只在非写入操作中使用重试。
Q2：为什么我设置了重试，但还是失败了？
A：可能是重试间隔太短。如果 API 报错是因为“服务器内部错误”（500），通常需要较长时间恢复。建议将第一次重试的等待时间设置为 5-10 秒，并采用指数退避策略（即每次重试等待时间加倍）。
Q3：如何查看历史失败记录？
A：n8n 的执行记录默认只保存一段时间。如果你需要长期审计，建议使用 Node.js 节点或 HTTP Request 节点，将错误日志同步到 Elasticsearch、Google Sheets 或专门的日志服务器中。
总结与资源
在 n8n 的世界里，稳定性和功能性同样重要。错误处理不是“锦上添花”，而是“雪中送炭”。通过合理配置 Continue On Fail、Retry On Fail 以及 On Error 重工作区，你可以构建出能够自我修复的健壮系统。
记住 N8N大学 的核心理念：**自动化是为了解放双手，而不是增加维护负担。** 花 10 分钟配置好错误处理，可能为你节省未来 10 小时的 Debug 时间。
如果你想深入学习 n8n 的高级节点用法，欢迎访问 n8ndx.com，这里有更多硬核的实战教程等你来啃。
