最近在做n8n工作流的时候,遇到了两个挺常见但容易踩坑的问题:一个是把两个输入项合并成一个,另一个是根据多个条件来触发后续节点。这两个问题看起来简单,但实际操作起来有不少细节需要注意。
今天就把我的经验整理一下,希望能帮到遇到类似问题的朋友。
Code节点合并两个输入项
先说合并数据这个需求。在n8n里,Code节点有两种执行模式,合并数据的关键在于选对模式。
用对执行模式
Code节点的默认模式是”Run Once for All Items”,这个模式下,所有输入项会以数组形式传进来,代码只执行一次。要合并数据,就得用这个模式。
配置很简单,把两个分支的数据都连到Code节点,确保Mode选项是”Run Once for All Items”就行。
几种合并方式
我平时常用的有三种写法:
第一种,用展开运算符:
const mergedObject = { ...items[0].json, ...items[1].json};
return [{ json: mergedObject }];第二种,用Object.assign:
const mergedObject = Object.assign({}, items[0].json, items[1].json);return [{ json: mergedObject }];第三种,如果输入项多于两个或者想更精细控制:
const outputJson = {};
for (const item of items) { Object.assign(outputJson, item.json);}
return [{ json: outputJson }];容易忽略的坑
这几个坑我踩过,分享一下:
数据顺序很重要。items数组里元素的顺序跟数据流入Code节点的顺序有关,如果顺序乱了,合并结果可能不是你想要的。
**属性覆盖问题。**如果两个输入项有同名的属性,后面那个会覆盖前面的。比如items[0]有name: "Alice",items[1]有name: "Bob",合并后name就是”Bob”。
**空值处理。**如果某个分支可能没有数据,代码里要加判断,比如if (items.length > 1),不然会报错。
其实还有个更简单的方案
如果你的合并逻辑比较简单,比如只是追加数组或者根据键值匹配,其实可以不用Code节点,n8n有个专门的Merge节点。这个节点对于简单的合并场景更直观,也不需要写代码。
多条件判断触发节点
再说第二个问题,根据多个条件来触发节点。这个需求在n8n里很常见,实现方式有好几种。
IF节点 + Merge节点(最推荐)
这是处理多条件判断最标准的方法,特别适合需要检查多个独立条件的场景。
思路是这样的:
- 用Switch节点把流程拆成多个分支,每个分支检查一个条件
- 在每个”条件通过”的分支后面加个Set节点,设置一个标志,比如
condition1Met = true - 用Merge节点的Wait模式,收集所有分支的结果
- 最后用Code节点或IF节点检查所有标志是否都为true
我常用的代码是这样的:
const allConditionsMet = items.every(item => item.json.condition1Met === true);
if (allConditionsMet) { return [items[0]];}
return [];如果所有条件都满足,就返回数据继续往下走;不满足就返回空数组,流程就停了。
单个IF节点用表达式
如果条件比较简单,而且所有数据都在同一个JSON对象中,其实可以不用拆分支,直接在IF节点里用表达式就行。
比如要检查多个条件同时满足:
{{ $json.isPremiumUser === true && $json.hasValidPayment === true }}或者检查任意一个满足就行:
{{ $json.isPremiumUser === true || $json.hasValidPayment === true }}这种方式配置起来很快,但如果条件很复杂或者数据来自不同源头,表达式会变得很难维护。
Switch节点做路由
Switch节点适合根据一个字段的不同值,把流程导向完全不同的节点。但它不太适合做”等待多个条件同时满足”这种逻辑,更多是用来做路由。
怎么选?
简单总结一下:
- 如果是多个独立条件需要聚合判断,用IF + Merge,虽然节点多一点,但逻辑最清晰
- 如果条件简单且数据在同一对象中,单个IF表达式就行
- 如果是根据单一字段做多路路由,用Switch节点
实战中的小建议
折腾这些流程的过程中,我总结了几点经验:
**先画个流程图。**特别是多个条件分支的时候,先在纸上把逻辑画清楚,比直接在n8n里拖节点要快多了。
**命名要规范。**Set节点里的标志字段,用condition1Met、condition2Met这种命名,后面写代码的时候不容易搞混。
**测试要充分。**多条件判断的逻辑容易出bug,每个分支都要测试一下,特别是边界情况。
**考虑性能。**如果条件分支很多,用Code节点一次性判断可能比多个IF节点效率更高。
最后说两句
n8n的功能很强大,但有时候实现一个需求会有多种方式。关键是要理解每种方式的适用场景,选对了方法,工作流会更清晰,也更容易维护。
这些方案都是我在实际项目中踩坑后总结出来的,如果你有更具体的场景或问题,欢迎一起交流探讨。