我在每个项目中使用的 5 种 n8n 工作流模式

Source: Dev.to

错误处理子工作流

不要在主工作流中到处散布错误处理逻辑。创建一个专用的错误处理子工作流：

Main Workflow → On Error → Call Error Handler Sub-Workflow

错误处理器应当：

• 记录完整的错误上下文
• 发送警报（Slack/邮件）
• 保存失败的项目以便重试
• 追踪错误发生频率

在一个地方统一管理所有错误逻辑。

在开头使用配置节点

在每个工作流的第一个节点放置一个 Set 节点，用于配置：

{
  "env": "production",
  "batchSize": 100,
  "retryAttempts": 3,
  "alertChannel": "#ops-alerts",
  "dryRun": false
}

无需修改其余逻辑即可改变行为。可以在此处切换干运行模式、调整批量大小等。

幂等性检查

在处理任何项目之前，先确认它是否已经被处理过：

// Check processed items table
const alreadyProcessed = await checkDatabase(item.id);
if (alreadyProcessed) {
  return []; // Skip
}

这可以防止：

• 重复发送邮件
• 双重收费
• 重复的 API 调用

对于可能会重试的工作流尤为重要。

批量 + 延迟模式

当调用受速率限制的 API 时：

Split In Batches (10 items) → Process → Wait (1 second) → Loop

简单却能避免大多数速率限制问题。根据 API 的限制调整批量大小和延迟时间。

健康检查工作流

单独的工作流用于监控其他工作流：

• 检查执行历史是否有失败
• 验证预期的运行是否已发生
• 测试关键 API 连接
• 若出现异常则发送警报

每小时运行一次，提前发现问题，而不是等用户发现。

额外：日志记录模式

每个工作流都应记录：

• 开始时间和触发信息
• 处理的项目数量
• 被跳过的项目及原因
• 持续时间和结果

将日志存入简单的数据库，甚至是 Google Sheet。对调试价值巨大。

实施技巧

从简单开始。 不必在每个工作流里一次性加入所有模式，按需逐步引入。

使用子工作流。 错误处理、日志记录和通知应当可复用。

记录决策。 在 n8n 中添加注释，说明 为什么 这样实现。

版本控制。 定期导出工作流并存入 Git。

结果

工作流能够：

• 优雅地处理失败
• 易于调试
• 在高负载下不崩溃
• 安全地进行修改

这就是原型与生产环境之间的差别。

更多生产模式请参见