n8n子工作流是什么？怎么用（入门教程）

如果你已经用 n8n 搭过几条像样的自动化，多半遇到过同一个问题：节点越加越多，画布越来越复杂。改一处要翻半天，复制粘贴还容易漏改。

这篇文章我们讲一种很实用的解法：子工作流（Sub-workflow）。你可以把它理解成编程里的「函数」：把一段通用逻辑单独做成一个工作流，主流程里只保留一句「调用它」，需要改通知渠道、改消息格式时，只动子工作流即可。

下面我们详细介绍一下子工作流是什么，如何用。

一、子工作流是什么？

在 n8n 里，子工作流就是一个被其他「主工作流」调用的独立工作流。主流程通过专用节点发起执行，子流程从专用触发器开始跑自己的节点链，再把结果交还给主流程（如果你需要返回值的话）。

它和「把节点复制到每个流程里」最大的区别是：逻辑只维护一份，调用方只关心「传什么、要不要等结果」。

tips：节点名称提示： 当前官方文档与新版界面里，调用端节点一般叫 Execute Sub-workflow，子流程起点叫 Execute Sub-workflow Trigger（在触发器列表里也可能显示为 *When Executed by Another Workflow*）。若你仍在旧版本上看到 Execute Workflow / Execute Workflow Trigger，功能对应关系是一样的。

二、为什么要用子工作流？

• 复用性： 写一次，到处用。格式化时间、统一鉴权、统一发通知，都适合抽成子工作流。
• 整洁度： 主工作流如果堆到几十个节点，阅读和排错成本会指数上升。把「通知」「清洗」「上传」拆出去，主流程只保留业务主线。
• 易维护： 子工作流改一处，所有调用它的主流程同步受益，不用逐个打开改副本。
• 错误隔离： 出问题更容易定位：是主流程的业务判断错了，还是子流程里的模板错了。

补充一个官方层面的好处： 根据官方说明，子工作流的执行通常不计入你套餐的月度执行次数或「活跃工作流」限制（如果你是购买的n8n官方云端版本的）。这对「高频被调用的小工具流」很友好。

三、核心机制：两个节点 + 数据怎么走

要用好子工作流，我们需要记住这一对组合：

位置	节点	作用
子工作流	Execute Sub-workflow Trigger	声明「这条流是给别人调用的」，并接收主流程传来的数据
主工作流	Execute Sub-workflow	选择要调用的子工作流，并把当前 item 的数据传过去

数据传递（官方描述的核心链路）：

1.主工作流里的 Execute Sub-workflow 把数据交给子工作流的 Execute Sub-workflow Trigger。

2.子工作流跑完后，最后一个节点的输出会回到主工作流里的 Execute Sub-workflow（便于主流程继续往下接节点）。

因此：如果你希望「有返回值」，通常要保证子工作流最后一段输出的 JSON 结构，正是主流程下一节点需要的结构（必要时在子流程末尾加一个 Set / Code 做统一收口）。

四、创建子工作流：可以按这个顺序来做

1. 新建一条工作流

给它起一个一眼能认出的名字，例如：[Sub] Global-Notifier。

2.限制「谁能调用我」

在子工作流的 Settings 里，可以配置 This workflow can be called by（哪些工作流允许调用本流）。团队环境或对外实例上，这是一个很实用的安全闸。

3. 放好触发器，并选对「输入模式」

添加 Execute Sub-workflow Trigger。在触发器里需要设置 Input data mode，常见三种：

• Define using fields below：在触发器里声明字段名和类型，主流程的 Execute Sub-workflow 会自动出现对应输入项，适合「接口化」的子流程。
• Define using JSON example：用一段示例 JSON 描述输入结构，适合结构略复杂、字段较多的情况。
• Accept all data：不设必填结构，主流程传什么就吃什么；灵活，但子流程要自己处理缺字段、类型不一致等问题。

实操建议： 像报警机器人这种字段固定的场景，优先用 Define using fields below，主流程填参不容易漏。

4. 接上你的业务节点并保存

官方还强调一点：子工作流本身不能有错误配置（存在错误时，父工作流可能无法成功触发它）。所以上线前，先在子流程里单独跑通一次。

五、在主工作流里调用：Execute Sub-workflow 怎么配

1. 添加 Execute Sub-workflow 节点

2. 选择子工作流

常见做法是 Source: Database，再从列表里选中你保存好的子工作流。你也可以按官方支持的方式，用 ID / 本地文件 / JSON / URL 等来源定位子工作流（迁移、备份恢复时会用到）。

3. 填好子流程声明的输入项

如果子流程触发器用字段定义了 project_name、severity 等，这里就会对应出现输入框，直接映射或手写即可。

4. 是否需要「等子流程跑完」

很多版本里，Execute Sub-workflow 提供类似 Wait for Completion（等待完成） 的选项（不同版本文案可能略有差异）：

• 开启（默认常见行为）： 主流程停在这里，等子流程结束并带回输出，再继续。
• 关闭（类似 Fire and Forget）： 主流程触发后立刻往下走，不等待子流程结果（适合「只要通知出去，不关心返回」的旁路任务，但要自己评估时序与错误处理）。

5. 只想传部分字段怎么办？

在主流程里，Execute Sub-workflow 之前加一个 Edit Fields (Set)，把 $json 整理成子流程需要的扁平结构，能显著减少「传了一大坨用不上的数据」带来的困扰。

执行时，你可以在 Execute Sub-workflow 节点里通过 View sub-execution 跳到子执行记录，排错路径很清晰。

六、案例：报警机器人（Universal Notifier）

我们经常会遇到这种问题：可能有 10 条完全不同的自动化（发薪资、查库存、监控网站……）。如果每条流程出错时都要重复配置「飞书机器人 / 钉钉 / Discord、消息模板、重试逻辑」，维护成本会迅速爆炸。

所以，我们可以做一个 报警子工作流：任何主流程只要负责判断「出事了」，把结构化信息丢给子流程；格式化 + 投递渠道统一在子流程维护。主流程写业务，子流程写通知。

1.子工作流：[Sub] Global-Notifier

节点 1：Execute Sub-workflow Trigger

①输入模式选择：Define using fields below

②定义字段（示例）：

• project_name（文本）：项目名
• error_msg（文本）：错误信息
• severity（文本）：严重程度（例如：紧急 / 一般）

节点 2：Edit Fields (Set)

我们把字段拼成一条可读性强的消息，比如：

{{ `🚨 报警通知
项目：${$json.project_name}
级别：${$json.severity}
详情：${$json.error_msg}
时间：${$now.toFormat('yyyy-MM-dd HH:mm:ss')}` }}

这里我们在set里定义了一个message的字段，把上面的内容输出的message，并供下游节点使用。

节点 3：获取飞书token，发送飞书消息

获取token我们就不详细说了，主要说下发送飞书消息的节点

调用飞书发送消息的API，https://open.feishu.cn/open-apis/im/v1/messages

在body里，把消息定义在json里

{{ JSON.stringify({
  receive_id_type: "open_id",
  receive_id: "ou_f97328cd75b56f947e5546c4d01e1fea",
  msg_type: "text",
  content: JSON.stringify({ text: $('Edit Fields').item.json.message })
}) }}

2.主工作流：[Main] Web-Monitor（网站监控示意）

节点 1：Manual Trigger 或 Schedule Trigger

按你的需求定时或手动跑。

节点 2：HTTP Request

写上我们需要监控的网页地址

节点 3：If

判断状态码是否为 200（或你自定义的健康条件）。失败走 True（或 False，按你分支习惯统一即可）。

节点 4：Execute Sub-workflow

在Workflow，选择我们上一步搭建的子流程 [Sub] Global-Notifier，把主流程和子流程关联起来。

Workflow Inputs：我们把project_name、error_msg和severity的内容定义好

这样，当我们运行主流程时，子流程就会自动触发并运行

比如上面的例子，运行后，我们就可以在飞书里收到消息提醒。

七、常见应用场景

统一错误处理： 任何主流程 Error Workflow 或失败分支调用「报警子流程」，把 workflow name / node name / error message 标准化传进去。

数据清洗： 复杂 JSON 展开、字段重命名、补默认值，全部收口到子流程；主流程只做「取数—调用—落库」。

批处理配合 Split In Batches： 对一组 items 逐条调用子流程，控制并发与内存（注意子流程要被设计成幂等、可重试）。

八、需要注意的「坑」

1.ID 依赖与环境迁移

n8n 往往通过 workflow ID 关联子工作流。你从本机迁到服务器、从测试迁到生产时，记得重新检查 Execute Sub-workflow 指向的是否仍是目标环境里的那条流。

2.避免无限循环

千万不要出现 A 调用 B，B 又调用 A（或更长链条绕回自己）。这很容易导致执行爆炸，把实例拖垮。子工作流要有清晰的单向依赖。

九、小结

子工作流的本质，是把 n8n 从「一坨大脚本」拉回到「模块化服务」：主流程讲业务，子流程沉淀通用能力。

你可以先用 全能报警机器人 这种低耦合场景练手：字段少、回报清晰、马上能复用到多条主流程里。

---