子工作流与模板复用
第 19 章:子工作流与模板复用
随着你的 n8n 工作流数量增长,重复代码问题开始显现:每个工作流里都有一段几乎相同的"飞书通知"逻辑,每次修改通知格式都要逐一更新几十个工作流。子工作流(Sub-workflow)是 n8n 解决这个问题的核心机制——将公共逻辑封装为独立工作流,通过 Execute Workflow 节点调用,一处修改全局生效。本章还将讲解工作流模板导入导出、版本管理和团队协作权限设置。
19.1 Execute Workflow 节点基础
Execute Workflow 节点(在节点面板搜索 "Execute Workflow")允许一个工作流同步调用另一个工作流,等待其执行完成并获取返回值。这是 n8n 实现代码复用的核心节点。
工作原理:
- 父工作流执行到 Execute Workflow 节点时,暂停并触发指定的子工作流
- 子工作流使用 Execute Workflow Trigger 节点作为起点(而非 Webhook 或 Schedule)
- 子工作流执行完毕后,将最后一个节点的输出返回给父工作流
- 父工作流继续向下执行
同步 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 目前的版本管理能力有限(企业版有内置版本历史),自托管用户可以通过以下方式实现版本控制:
- 手动导出 + Git:修改重要工作流前,先导出 JSON 并提交到 Git。回滚时导入历史版本的 JSON。
- 命名约定:给工作流名称加版本号,如"内容流水线 v2.3",旧版本工作流设为停用(Inactive)而非删除。
- n8n CLI 导出:使用 n8n 命令行工具批量导出所有工作流,可以集成到 CI/CD 中定期备份。
# 在 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)应由管理员创建并共享给相关成员,成员只能使用凭证,无法查看原始密钥值。