工作流报错停止咋办？错误节点如何排查？

工作流突然罢工？别慌，Dr. n8n 教你三步定位“罪魁祸首”

上周帮一家跨境电商客户排查自动化流程时，他们正焦头烂额：订单一进来，整个工作流就卡在“发送 Slack 通知”节点不动了。老板以为是 API 配额用完了，技术小哥怀疑是网络波动——结果呢？只是一个 JSON 路径写错了字段名。这种“小错酿大祸”的场景，我见得太多了。

💡 自动化不是魔法，它像一条精密的流水线——任何一个齿轮卡住，整条产线都会停工。关键不是“会不会出错”，而是“出错后怎么快速揪出问题节点”。

第一步：看“红灯区”——错误日志是你的第一现场

当 n8n 工作流报错停止时，第一个动作不是重启，而是点开那个标红的节点。90% 的错误信息其实已经明明白白写在那里了。比如：

• Cannot read property 'email' of undefined —— 说明上一个节点没传过来 email 字段，或路径写错了。
• 401 Unauthorized —— 像进公司大楼没带门禁卡，API 密钥失效或权限不足。
• Timeout after 30s —— 对方服务器睡着了，或者你请求的数据太大，超时了。

我在给某 SaaS 客户搭建“自动创建客户+分配销售”的流程时，就遇到过因 HubSpot API 返回结构变更，导致后续节点取不到 company_id。解决方案？加个 IF 节点做空值判断，再加个 Set 节点兜底默认值——流程立刻稳如老狗。

第二步：模拟“快递分拣”——用 Debug 节点追踪数据流向

想象你的工作流是一条快递分拣线：包裹（数据）从入口进来，经过扫码、称重、贴标、装车… 如果在“贴标机”环节卡住了，你是该修机器，还是该检查包裹本身？

这时候，Debug 节点就是你的 X 光机。把它拖到疑似出错的节点前，运行一次，就能看到此刻数据长什么样。实操建议：

1. 在报错节点前一个节点后插入 Debug 节点。
2. 运行工作流，查看 Debug 输出的 JSON 结构。
3. 对比你期望的字段路径（比如 {{ $json.user.email }}），看是不是少了一层嵌套，或多了一个复数 s。

// 示例：Debug 节点输出可能长这样
{
  "user": {
    "profile": {  // 注意！email 藏在 profile 里，不在 user 直接下
      "email": "user@example.com"
    }
  }
}
// 所以正确路径应为 {{ $json.user.profile.email }}，而非 {{ $json.user.email }}

第三步：构建“安全网”——用错误处理机制让流程永不中断

真正的高手，不是不出错，而是让错误“无害化”。n8n 提供了强大的错误处理（Error Handling）功能，相当于给每个节点装上“保险丝”——局部短路，不烧整栋楼。

设置方法很简单：

1. 选中任意节点 → 点击右侧面板的 “Add Error Handler”。
2. 拖入一个新节点（比如 Send Email 或 Write to Google Sheet），专门记录错误详情。
3. 勾选 “Continue On Fail”，即使这个节点挂了，工作流也能继续跑下去。

我给一个金融客户做的“自动对账流程”，就在每个外部 API 调用后都加了错误处理器：一旦失败，自动发邮件给运维 + 把原始数据存入备份表。三年来零中断，客户说这是他们最稳的自动化系统。

总结：报错不是终点，而是优化的起点

工作流报错不可怕，可怕的是盲目重启或放弃。记住 Dr. n8n 的排查三板斧：看日志 → 插 Debug → 加保险。把每一次报错，都当成一次“系统体检”，你的自动化肌肉才会越来越强壮。

👇 你在 n8n 里踩过最坑的报错是什么？是在哪个节点翻的车？评论区留下你的“血泪史”，我们一起帮你复盘！