n8n条件调试指南：解决类型敏感与跨节点引用问题（附：判断失效排查步骤）

你的“条件判断”为何总失效？从类型陷阱到跨节点迷宫的实战拆解

上周，一位做跨境电商的朋友深夜给我发消息：“Dr. n8n，我的订单自动分拣流程明明设置了‘金额 > 500 才触发VIP服务’，结果100块的订单也被塞进去了！条件节点是摆设吗？”——这绝非个例。在n8n社区里，“条件判断不生效”常年稳居报错榜首。今天，我就带你用外科手术刀级别的精度，剖开那些藏在数据类型和节点引用里的“幽灵Bug”。

第一刀：类型敏感——数字、字符串、布尔值的“身份危机”

想象你走进一家高级餐厅，服务员问：“先生几位？”你答“2”，他点头安排双人桌；但如果你答“二”，他可能一脸懵——这就是类型敏感的日常版。在n8n里，条件节点对数据类型的挑剔程度有过之而无不及。

我在帮某母婴品牌搭建“库存预警+自动补货”系统时踩过巨坑：上游API返回的库存数是字符串“"15"”，而我的条件写的是“小于 20”。结果系统永远沉默——因为字符串“15”和数字20根本不在一个维度比较！

解决方案三步走：

1. 显式转换：在条件节点前插入Function Item节点，用JavaScript强制转换：

   // 将字符串转为数字
   return {
     ...item,
     stock: Number(item.json.stock)
   };

2. 调试利器：善用Set节点 + Console Log，把可疑字段打印出来，肉眼确认类型。
3. 防御性编程：在条件表达式里直接包裹转换函数，比如：Number($json.amount) > 500。

第二刀：跨节点引用——当“上家”的数据突然“失联”

你让实习生小王去财务部拿报销单（节点A），再交给行政部盖章（节点B）。结果小王空手而归：“财务说没这单子！”——问题可能出在：财务部给的是“电子编号”，而行政部只认“纸质单号”。在n8n里，跨节点引用失败，90%是因为路径错误或数据结构嵌套太深。

常见症状：

• 写$node["Webhook"].json["user.email"]报错“Cannot read property 'email' of undefined”
• 明明Webhook收到了完整JSON，下游节点却读不到任何值

排查四步法：

1. 回溯源头：在目标节点前加Debug节点，完整输出上游节点的Output，确认数据是否存在、路径是否正确。
2. 路径校准：使用n8n的Expression Editor自动补全功能。点击输入框旁的魔法棒图标，它会列出所有可用字段，避免手打路径拼错。
3. 处理数组：如果上游返回的是数组（如[{id:1, name:"Alice"}, {id:2, name:"Bob"}]），必须用$json[0].name指定索引，或配合Item Lists节点拆分处理。
4. 兜底策略：用??操作符设置默认值，防止undefined导致流程中断：$json.user?.email ?? "default@example.com"

终极武器：条件判断失效的“五步急诊流程”

当你的条件节点又双叒失效时，别慌，按这张清单逐项排查：

结语：调试不是玄学，是系统工程

条件判断失效从来不是“运气问题”，而是数据类型、引用路径、执行时序共同编织的精密陷阱。掌握上述方法，你就能像拆弹专家一样，冷静剪断错误引线。现在轮到你了——你在n8n里遇到过最诡异的条件bug是什么？评论区留下你的“血泪史”，我们一起解剖！