在 n8n 的世界里，数据流就像城市的交通。如果把各个节点比作路口，那么 Merge（合并） 节点就是那个至关重要的立交桥。它决定了来自不同方向的数据流是擦肩而过、还是汇入同一条主干道。然而，很多 n8n 用户在面对 Merge 节点时，往往因为它那看似简单的“连接方式”选项而感到困惑，甚至导致整个自动化流程“交通瘫痪”。
作为 N8N大学 的首席主编，笔者见过太多因为 Merge 节点设置不当而导致的数据丢失或流程卡死的案例。今天，我们就来硬核拆解 Merge 节点的核心——“连接方式”，带你像老司机一样，掌控数据流的生死。
Merge 节点的十字路口：它到底在做什么？
Merge 节点位于 n8n 的核心节点库中，它的本质是一个数据整合器。当你需要合并来自两个或多个前置节点的数据时，它就会登场。但这里的关键在于：数据流过来后，到底该怎么“接”？是全部保留、按顺序匹配，还是只取交集？
在 n8n 的 UI 中，Merge 节点的“连接方式”（Join Mode）主要分为几种模式：**Wait for All Inputs**（等待所有输入）、**Wait for First Input**（等待第一个输入）、**Wait for Specific Input**（等待特定输入）。这些模式直接决定了数据流是继续向下游传递，还是在此处戛然而止。
Wait for All Inputs：最稳妥的“集齐龙珠”模式
这是最常用，也是最稳健的模式。顾名思义，它要求所有连接到 Merge 节点的输入分支都必须有数据流到达，流程才会继续向下游执行。
场景应用： 比如你正在做一个用户注册流程，需要同时获取用户信息（来自 HTTP Request 1）和系统分配的初始积分（来自 HTTP Request 2）。只有当这两个数据都拿到手了，你才需要发送欢迎邮件（下游节点）。如果缺了一个，流程就不该继续。
关键设置： 在这个模式下，通常需要关注“合并方式”（Merge Mode）：
- Keep All Rows (Cross Join)：笛卡尔积。如果输入 A 有 3 条数据，输入 B 有 2 条数据，输出就是 3 * 2 = 6 条数据。适合做全排列组合。
- Keep Data from Input 1：只保留第一条输入的数据，如果第二条输入的数据过来，直接丢弃或仅作为触发条件。
- Wait for Data from Input 1 then Merge：这是 N8N大学 推荐的“安全模式”。它会等待所有输入，但输出结果以第一条输入的数据结构为主，将其他输入的数据作为新属性合并进去。
Wait for First Input：抢占先机的“赛跑”模式
在这个模式下，Merge 节点不再追求“大团圆”，而是变成了一个发令枪。只要有一个输入分支的数据到达，它就会立即触发下游流程，同时让其他还在半路上的数据流“作废”。
场景应用： 想象你在监控服务器状态，A 节点监控 CPU 使用率，B 节点监控内存使用率。你设置了一个报警机制：只要有一个指标超过阈值（触发了数据流），就立即发送报警邮件。你不需要等 CPU 和内存同时超标才报警，那样太危险了。
致命陷阱： 这里有一个巨大的坑。如果你的前置节点是定时触发（比如每小时一次），而另一个节点是 Webhook 触发（随时可能来）。选择“Wait for First Input”可能会导致定时任务在等待 Webhook 时超时，或者 Webhook 刚来就触发了，导致定时任务的数据被直接忽略。这往往是数据丢失的隐形杀手。
Wait for Specific Input：精准控制的“狙击手”模式
这是最灵活但也最考验逻辑的模式。你可以指定 Merge 节点只等待某一个特定输入分支的数据，而忽略其他分支。
场景应用： 假设你有一个复杂的电商订单流程。流程的主干是“等待支付成功”（来自支付网关的 Webhook），但同时你还有一个辅助分支在“同步库存信息”（定时任务）。你希望流程的核心逻辑只在支付成功时才继续（生成订单、发货），而库存同步的任务虽然挂在同一个 Merge 节点上，但不应该影响主流程的触发。
硬核技巧： 在设置时，你需要为每个输入端口（Input 1, Input 2...）明确指定是否为“等待目标”。这允许你在一个工作流中构建复杂的异步逻辑，让不同频率、不同触发源的数据流和谐共存，而不是互相打架。
如何决定数据流的生死？
回到标题的核心——如何用“连接方式”决定数据流的生死。这里的“生死”并非玄学，而是指数据能否通过该节点到达下游。
1. 严格模式（Wait for All）： 任何一个分支的失败或空数据，都可能导致整个流程停滞。这是“连坐制”，适合强依赖的业务逻辑。
2. 宽松模式（Wait for First）： 谁快谁赢，赢者通吃。这是“淘汰制”，适合报警、竞速类场景。
3. 混合模式（Wait for Specific）： 择优录取。这是“选拔制”，适合主从分明的异步业务。
笔者的避坑指南： 在 n8n 中，如果某个输入分支没有数据流出（例如 HTTP Request 返回 200 但无内容），Merge 节点可能会无限期等待。务必在 Merge 之前使用 If 节点或 Empty 节点做数据校验，确保“死掉”的数据流不会拖累“活着”的数据流。
FAQ 问答
Q1: Merge 节点会改变数据的 JSON 结构吗？
这取决于你选择的合并方式。如果是“笛卡尔积”（Cross Join），它会将两个输入的数据对象平铺合并，生成一个包含所有字段的新对象。如果是“Keep Data from Input 1”，它可能会将输入 2 的数据作为数组或对象嵌套在输入 1 的字段中。建议在测试时多点击“Execute Node”查看输出预览。
Q2: 为什么我的 Merge 节点一直处于“等待”状态？
最常见的情况是使用了“Wait for All Inputs”模式，但某个前置节点因为报错、网络问题或判断逻辑（如 If 节点）导致没有数据流出。n8n 会一直等待直到超时。检查每个分支的路径，确保它们都能正确到达 Merge 节点。
Q3: Merge 节点可以合并 10 个以上的输入吗？
技术上可以，n8n 没有严格的输入上限。但从实践角度看，超过 5 个输入的 Merge 节点会让工作流变得极难维护和调试。N8N大学 建议如果逻辑过于复杂，可以考虑拆分为多个 Merge 节点，或者使用 Code 节点（JavaScript）来手动编写合并逻辑，这样更可控。
总结与资源
Merge 节点是 n8n 中数据流向的“总调度师”。理解“连接方式”不仅仅是为了让流程跑通，更是为了构建健壮、容错的自动化系统。记住，没有最好的模式，只有最适合你当前业务逻辑的模式。
如果你在 Merge 节点的使用中遇到更棘手的场景，欢迎访问 N8N大学 社区，与更多实战派的开发者交流经验。下一次，我们将深入探讨 Code 节点与 Merge 节点的高级配合技巧，敬请期待。
