n8n 多路数据怎么合并：先决定追加、匹配还是找差异

先用两份小数据说清目标 假设一条分支返回客户资料，另一条返回客户状态。把两份列表直接追加，会得到两组记录；按客户身份匹配，才可能得到每位客户的一份完整信息。先画出期望输出，标明应该有几条记录、每条包含哪些字段，比先在画布上寻找“合并”按钮更容易避免歧义。 官方提供了哪几条路径 n8n 的合并指南把场景分为不同数据流或节点的合并、多个节点执行结果的汇总，以及先比较再输出。Merge 用于把不同来源的流组合起来，Compare Datasets 用于比较资料并产生不同输出流，Code 则适合更复杂的多次节点执行汇总。具体合并选项仍应查看所用节点版本。 把预期输出落到 Merge 的选项 用自拟资料测试：Input 1 有 C01、C02 两位客户的姓名，Input 2 有 C02、C03 的状态。选择 Append，预期是四条原始记录依次输出；它没有把同一个 C02 拼成一条。若要合并字段，选择 Combine → Matching Fields，并把双方的客户 ID 字段作为匹配依据。 接着选择输出范围。Keep Matches 只保留匹配的 C02；Enrich Input 1 保留 C01、C02，并给能匹配的 C02 补状态；Keep Everything 还保留只在第二份出现的 C03。名称不同的 ID 字段也可以分别配置，不必先用显示顺序对齐。具体应选择哪项，由下游是否允许缺失状态决定。 如果一个客户 ID 对应两条状态记录，先定义业务含义：是历史记录都应保留，还是只要最新一条。Merge 的 Multiple Matches 可以选择包含全部或只取首个，但“首个”不自动代表“最新”。若业务只要最新记录，先明确排序和去重规则，再执行匹配。 匹配身份不能依赖显示顺序 编辑建议是在测试数据中故意打乱顺序。例如同一个客户在两份列表的位置不同，检查输出是否仍属于正确的人。若业务依赖稳定 ID，应让测试围绕该身份展开；列表恰好同序只是一个样例现象，不应成为默认的对应关系。 继续测试缺失与重复 再加入只出现在第一份数据中的记录、只出现在第二份中的记录，以及重复身份。决定这些记录是保留、标记待补还是排除。若希望后续分别处理新增与已有数据，比较后分流通常比把所有结果塞入一条流再猜测来源更清晰。 不要混淆节点执行与工作流执行 官方特别说明，多次节点执行指同一次工作流运行中，一个节点被执行多次。它不是天然跨多次独立工作流运行的长期聚合。循环中汇总结果时，先确认数据来自哪些执行轮次，再决定是否需要 Code 整理；跨次运行的状态则应另行设计存储。 让验收落在数据上 保存输入记录数、输出记录数以及几条关键身份的对应关系。只看到节点变绿，无法证明没有丢失或重复记录。对于关联后字段重名的情况，也应核对最终值来自哪一侧。当前 Merge 文档默认优先采用 Input 2 的同名值；需要保留双方时，可在 Clash Handling 中调整冲突策略，再用一条两侧状态不同的记录验证。 完成标准 一条可维护的合并流程，应能解释每类输入最后去了哪里，并在缺失、重复和顺序变化时保持预期行为。若结果数出乎意料，先按具体客户 ID 查找其来源，再检查匹配范围、重复匹配与同名字段策略，不要只把输入数量相加当作正确输出数量。

本篇涉及的工具1

n8n

汇总、比较与组合多路数据

适合场景

需要汇总多个系统的数据、比较新旧记录或整理循环结果的 n8n 使用者。

需要留意

需以业务身份和缺失、重复样本验收输出。

了解项目 访问官网