n8n分支判断进阶：多重条件组合与判空逻辑详解（附：True/False输出流向解析）

“明明数据对了，流程却走错了路？”——分支判断的隐形陷阱

上周帮一家跨境电商客户调试退货自动化流程时，他们抱怨：“订单状态是‘已取消’，系统却自动发出了发货通知！”排查后发现，问题出在分支节点的多重条件组合上——他们用 AND 连接了三个字段判空，但其中一个字段其实是 undefined，导致整个表达式被短路，最终走了 False 分支。这不是个例。据我观察，80% 的 n8n 流程“逻辑跑偏”，都源于对分支节点中“条件组合”和“判空逻辑”的理解偏差。

分支不是开关，而是“逻辑门电路”

很多初学者把 n8n 的 IF 节点当成简单的“是/否”开关，其实它更像电子工程里的“与门、或门”。每个条件都是一个输入信号，True 或 False 就是高低电平，最终输出由你设定的“逻辑运算符”决定。

生活类比：想象你要出门——“带伞”这个动作，取决于“是否下雨”OR“天气预报说下午有雨”AND“你下午要外出”。这里就混合了 OR 和 AND，还隐含了“天气预报是否存在”的判空逻辑。

三步拆解：如何构建可靠的多重条件表达式

1. 第一步：明确每个字段的“存在性” —— 在写条件前，先用 {{ $json.field !== undefined }} 或 {{ !!$json.field }} 判空。尤其当数据来自 Webhook 或 API 时，字段缺失是常态，不是异常。
2. 第二步：用括号控制运算优先级 —— n8n 默认从左到右计算，但你可以用括号强制分组。例如：

   ({{ $json.status === 'cancelled' }} AND {{ !!$json.refund_amount }}) OR {{ $json.is_fraud === true }}

   这样能确保“状态+退款金额”作为一个整体，再与“是否欺诈”做 OR 运算。
3. 第三步：预演 True/False 的流向 —— 每个 IF 节点有两个出口：“When True” 和 “When False”。画一张纸，模拟不同数据组合下流程走向。我在给教育 SaaS 客户设计“课程提醒机器人”时，就因没预演“用户未绑定微信 AND 未留邮箱”的情况，导致提醒完全静默。

实战：电商订单状态机中的“五重保险”判空策略

以下是我为客户设计的真实表达式，用于触发“高风险订单人工审核”：

({{ $json.order_total > 5000 }}) AND
({{ !!$json.shipping_address }}) AND
({{ $json.payment_method !== 'COD' }}) AND
({{ $json.user_level !== 'VIP' }}) AND
({{ !$json.is_whitelisted }})

注意第五行的 !$json.is_whitelisted —— 这是典型的“负向判空”。如果白名单字段不存在（undefined），! 会将其转为 True，从而进入审核流。这正是业务需要的：未知用户一律视为高风险。

True/False 输出流向：别让“沉默的 False”毁了你的流程

很多人只关注“When True”分支，认为“When False”就是“啥也不干”。大错特错！False 分支同样是流程的一部分。我建议：

• 为 False 分支添加“日志记录节点”，写入“未触发原因”；
• 或连接“备用处理路径”，比如发送 Slack 提醒：“订单#123 因条件不满足未进入审核”；
• 极端情况下，用 Error Trigger 节点主动报错，避免静默失败。

总结：分支判断的本质，是“数据契约”的执行

每一次 IF 判断，都是你与数据的一次契约：“我承诺在 XX 条件下执行 YY 操作”。而多重条件与判空逻辑，就是这份契约的“细则条款”。忽略它们，流程就会“违约跑偏”。

现在轮到你了 👇 你在 n8n 分支判断中踩过什么坑？是在 AND 里漏了括号？还是被 undefined 坑过？在评论区留下你的“血泪史”，我们一起拆解优化！