第 19 章

子工作流与模板复用

第 19 章:子工作流与模板复用

随着你的 n8n 工作流数量增长,重复代码问题开始显现:每个工作流里都有一段几乎相同的"飞书通知"逻辑,每次修改通知格式都要逐一更新几十个工作流。子工作流(Sub-workflow)是 n8n 解决这个问题的核心机制——将公共逻辑封装为独立工作流,通过 Execute Workflow 节点调用,一处修改全局生效。本章还将讲解工作流模板导入导出、版本管理和团队协作权限设置。

19.1 Execute Workflow 节点基础

Execute Workflow 节点(在节点面板搜索 "Execute Workflow")允许一个工作流同步调用另一个工作流,等待其执行完成并获取返回值。这是 n8n 实现代码复用的核心节点。

工作原理:

  1. 父工作流执行到 Execute Workflow 节点时,暂停并触发指定的子工作流
  2. 子工作流使用 Execute Workflow Trigger 节点作为起点(而非 Webhook 或 Schedule)
  3. 子工作流执行完毕后,将最后一个节点的输出返回给父工作流
  4. 父工作流继续向下执行

同步 vs 异步: Execute Workflow 节点支持两种模式。同步模式(默认):父工作流等待子工作流完成后继续。异步模式:父工作流触发子工作流后立即继续,不等待结果(适合发送通知等无需返回值的场景)。

19.2 参数传递:父 → 子

在 Execute Workflow 节点中,通过 Workflow Input Data 配置项向子工作流传递数据。子工作流的 Execute Workflow Trigger 节点会接收这些数据作为第一个节点的输出。

// Execute Workflow 节点配置
{
  "name": "Execute Sub: 飞书通知",
  "type": "n8n-nodes-base.executeWorkflow",
  "parameters": {
    "workflowId": "={{ $vars.FEISHU_NOTIFY_WORKFLOW_ID }}",
    "mode": "sync",
    "workflowInputs": {
      "values": [
        {
          "name": "title",
          "value": "={{ $json.title }}"
        },
        {
          "name": "message",
          "value": "={{ $json.errorMessage }}"
        },
        {
          "name": "level",
          "value": "error"
        },
        {
          "name": "chatId",
          "value": "={{ $vars.OPS_CHAT_ID }}"
        }
      ]
    }
  }
}

推荐将子工作流的 ID 存储在 n8n Variables(全局变量)中,这样当工作流 ID 因迁移而变化时,只需修改一处。

19.3 返回值:子 → 父

子工作流的最后一个节点的输出,会作为 Execute Workflow 节点的输出返回给父工作流。因此,子工作流通常以一个 Set 节点结尾,明确定义要返回的字段。

// 子工作流最后一个节点(Set 节点)定义返回值
{
  "name": "Return Result",
  "type": "n8n-nodes-base.set",
  "parameters": {
    "assignments": {
      "assignments": [
        {
          "name": "success",
          "value": true,
          "type": "boolean"
        },
        {
          "name": "messageId",
          "value": "={{ $('发送飞书消息').item.json.data.message_id }}",
          "type": "string"
        },
        {
          "name": "sentAt",
          "value": "={{ $now.toISO() }}",
          "type": "string"
        }
      ]
    }
  }
}

父工作流可以通过 $('Execute Sub: 飞书通知').item.json.success 获取子工作流的返回值。

19.4 公共逻辑封装实践

将以下常用模块封装为子工作流,可以大幅提升团队工作流的可维护性:

飞书通知模块

接受参数:title(标题)、message(正文)、level(info/warn/error)、chatId(目标群 ID)。根据 level 自动选择消息颜色和图标,发送富文本消息卡片。一旦飞书 API 调整,只需修改此一个子工作流,全部业务工作流自动生效。

错误处理模块

作为工作流的错误回调(在工作流设置中将"Error Workflow"指向此工作流)。自动获取出错的工作流名称、节点名称、错误信息,格式化后发送告警到运维群,并将错误记录写入 MySQL 的 workflow_errors 表。

最佳实践: 为所有生产工作流设置同一个错误处理子工作流(Workflow Settings → Error Workflow)。这样只需维护一处错误处理逻辑,且每次工作流报错都有统一的日志记录和告警通知,大幅降低运维成本。

19.5 工作流模板:导入与导出

n8n 支持将工作流导出为 JSON 文件,并可一键导入到任何 n8n 实例。这是团队内部共享和知识传承的重要方式。

导出工作流

在工作流编辑器中,点击右上角菜单 → "Download" → 选择 JSON 格式。导出的 JSON 包含所有节点配置,但不包含 Credentials(凭证)信息,这是安全设计。

从 n8n 模板库导入

n8n 官方维护了一个公共模板库(n8n.io/workflows),收录了数千个社区贡献的工作流模板。在 n8n UI 中点击"Templates"按钮,搜索关键词即可一键导入。导入后只需补充凭证信息即可使用。

团队内部模板库

建议在企业内部建立一个模板仓库(Git 仓库),按业务场景分类存放工作流 JSON 文件:

n8n-templates/
├── common/                  # 公共模块
│   ├── feishu-notify.json   # 飞书通知子工作流
│   ├── error-handler.json   # 错误处理子工作流
│   └── send-email.json      # 邮件发送子工作流
├── marketing/
│   ├── content-pipeline.json
│   └── social-post.json
├── devops/
│   ├── deploy-notify.json
│   └── issue-triage.json
└── README.md                # 每个模板的使用说明

19.6 工作流版本管理与回滚

n8n 目前的版本管理能力有限(企业版有内置版本历史),自托管用户可以通过以下方式实现版本控制:

# 在 n8n 容器内执行,导出所有工作流到 JSON 文件
docker exec -it n8n-n8n-1 \
  n8n export:workflow \
  --all \
  --output=/home/node/.n8n/exports/

# 在宿主机上将导出文件复制出来
docker cp n8n-n8n-1:/home/node/.n8n/exports/ ./workflow-backups/$(date +%Y%m%d)/

# 提交到 Git
cd ./workflow-backups
git add . && git commit -m "chore: workflow backup $(date +%Y-%m-%d)"

19.7 团队协作:共享与权限设置

n8n 的工作流默认只有创建者可以访问和编辑。在多人团队中,需要配置工作流共享权限:

权限级别 能力 适用场景
Owner(拥有者) 完全控制,可删除 工作流创建者
Editor(编辑者) 可查看和修改,不可删除 团队成员协作开发
Viewer(查看者) 只读,不可修改 审计、知识共享

配置方法:打开工作流 → 点击右上角菜单 → "Share" → 添加团队成员并分配角色。对于公共子工作流(如飞书通知模块),建议给所有团队成员设置 Editor 权限,并约定修改前需在 Slack/飞书群通知。

Credentials 共享注意: 凭证(Credentials)有独立的共享机制。团队共用的 API Key(如飞书机器人 Token)应由管理员创建并共享给相关成员,成员只能使用凭证,无法查看原始密钥值。

本章评分
4.6  / 5  (10 评分)

💬 留言讨论