引言

在实际的 n8n 工作流中，你很少会遇到一条直线执行到底的情况。更常见的是将流程分叉：一个分支查询你的 CRM，另一个获取分析数据，第三个则等待来自客户的 webhook。在某个时刻，你需要把这些并行分支重新合并到一起——这正是 Merge 节点的用途。正确理解如何合并分支可以防止数据丢失、重复处理，以及那些只在生产环境中才会暴露的隐蔽 bug。

本课涵盖 n8n 中三种主要的合并策略：等待所有输入完成、通过匹配键进行合并（类似 SQL 的连接），以及追加（拼接）所有传入的条目。每种策略服务于不同目的，选错策略是构建复杂自动化时最常见的错误之一。

Merge 节点的工作原理

Merge 节点接收多个输入流（Input 1、Input 2，可选更多）并产生单一的输出流。它只有在每个已连接的输入都至少送达一个条目后才会执行，这意味着它会隐式地同步各个分支。这就是「等待」行为：无论某个分支完成得多快，Merge 节点都会暂停，直到最慢的分支到达。

你也可以在节点设置中添加超时。如果某个分支永远不完成，合并最终会停止等待，并丢弃数据或以已到达的内容继续执行。这对于某些外部 API 可能挂起的长时间运行工作流很重要。

按键合并（Join 行为）

这是最接近 SQL JOIN 的等价方式。你选择一个在两个输入流中都存在的字段（例如 `email` 或 `orderId`），节点会配对具有相同值的条目。默认情况下，未匹配的条目会被丢弃，但你可以配置模式使其表现为 LEFT JOIN（保留 Input 1 中未匹配的条目）或外连接。

结果是每个匹配产生一个条目，来自两个输入的字段被合并在一起。下拉选项包括：

Append（追加）：按顺序将两个输入的所有条目连接成一个扁平列表，不进行配对。当两个分支产生独立的记录、之后只需统一处理时使用（例如，来自 Mailchimp 的所有联系人和来自 HubSpot 的所有联系人，排队等待后续统一去重）。

Merge By Key（按键合并）：通过共享字段配对条目，类似于数据库连接。当一侧的每个条目与另一侧的某个条目逻辑对应时使用，例如将订单记录与其对应的支付记录进行匹配。

Wait（等待）：最简单的模式——不做任何转换，只同步时序。输出条目按 Input 1 的顺序排列，Input 2 的条目按位置一对一附加。只有当你完全控制两个分支并明确知道顺序一致时才使用。

Mode 下拉框包含以下四个选项：Append、Merge By Key、Merge By Position 和 Wait。注意，「Merge By Position」是简单等待-配对行为的技术名称——它通过条目在输入数组中的索引进行配对，只有当两个分支具有相同数量且顺序一致的条目时才能正确工作。

实际示例：合并订单和支付数据

假设分支 1 从数据库中拉取订单，分支 2 从 Stripe 拉取支付状态。每个分支生成的条目都有一个 `orderId` 字段。你希望每个订单对应一条合并记录。

{
  "node": "Merge",
  "type": "n8n-nodes-base.merge",
  "parameters": {
    "mode": "mergeByKey",
    "joinMode": "inner",
    "propertyName1": "orderId",
    "propertyName2": "orderId"
  }
}

将 `joinMode` 设置为 `inner` 时，只有两个分支中都存在的订单才会出现在输出中。如果切换为 `left`，则尚无支付记录的订单仍会向下游流转，并标记为未匹配——这对于发现缺失的支付非常有用。

常见错误与陷阱

最常见的错误是在两个分支产生不同数量条目时使用「Merge By Position」。如果分支 1 返回 10 个订单，分支 2 只返回 7 条支付记录，那么其中 3 个订单条目要么与 `null` 支付数据配对，要么根据设置被静默丢弃。只要数量可能不同，就应该始终使用「Merge By Key」。

另一个陷阱：Merge 节点不会去重。如果分支 1 中同一个 email 出现两次，而分支 2 只出现一次，你可能会得到重复的连接行。去重必须在合并之前完成，或者通过单独的节点在之后处理。

最后，请记住 Merge 会等待每个已连接的输入。如果你忘记连接某个输入，节点将永远等待（或直到超时）。未连接的输入是生产环境中工作流挂起的常见原因。

小结

Merge 节点是任何多分支工作流的同步点。当你只是想堆叠独立列表时使用 Append；当两侧条目通过共享标识符相关联时使用 Merge By Key；仅当两个分支产生长度一致的匹配数组时才使用 Wait / Merge By Position。务必检查每个输入都已连接，选择与数据完整性需求匹配的连接模式，并将去重逻辑放在合并之外以避免意外。