Switch 节点：你以为的“分叉路口”，其实是“迷宫入口”
在 N8N大学 的自动化实战群里，每周都有人问：“为什么我的 Switch 节点明明设置了条件，数据却流到了不该去的地方？”
说实话，Switch 节点（Switch Node）是 n8n 里最基础但也最容易被轻视的节点。很多人觉得它不就是个“if-else”吗？插进去，设个条件，完事。但当你面对复杂的业务逻辑，比如“根据用户等级分配客服”、“根据订单金额决定是否通知老板”时，这个看似简单的节点往往会变成一团乱麻。
今天，笔者不讲枯燥的理论，只讲实战中那些教科书里不会提的坑。咱们一起把 Switch 节点彻底盘明白，让多路分流真正为业务服务。
模式识别：别把“菜刀”当“螺丝刀”用
很多新手踩的第一个坑，就是选错了 Switch Mode（模式）。n8n 给了你三个选择，选错一个，逻辑全崩。
- Node（节点）模式：这是最常用的。根据输出端口的数量，自动分配数据。比如你拉出 3 个输出口，数据就会按顺序（Round Robin）轮流发往这三个口。适合负载均衡。
- Expression（表达式）模式：这就是我们要重点讲的“逻辑分流”。你想根据数据内容决定去向，全靠它。
- Wait（等待）模式：这个比较特殊，用于等待特定事件触发，通常配合 Webhook 使用。
笔者的建议： 如果你是在做数据路由（比如：A 类数据走 A 通道，B 类走 B 通道），请毫不犹豫地选择 Expression。如果你选了 Node 模式，却发现数据并没有按你预想的条件分流，别怀疑代码，先检查模式设置。
条件设置的“文字游戏”：== vs ===
在 Expression 模式下，我们在每个输出端口设置判断条件。这里有一个极其隐蔽的坑：数据类型。
n8n 的表达式基于 JavaScript。在 JS 里，0 == false 是成立的，但 0 === false 是不成立的。很多 n8n 用户在设置条件时，习惯直接写：
{{ $json.status == 0 }}如果你的 JSON 数据里，status 是数字 0，这没问题。但万一某个接口返回的是字符串 “0” 呢？在某些环境下，“0” == 0 是 true，但如果你的数据源不稳定，这就会导致数据流向错误的端口。
避坑指南： 尽量使用严格相等（===）并强制转换数据类型。更稳妥的做法是先在前面的节点（如 Set 或 Code 节点）把数据类型清洗好，确保传入 Switch 的条件是确定的数字或字符串。
默认出口（Default）：被遗忘的垃圾桶
Switch 节点有一个默认输出口（通常标记为 Default 或 0）。这个口是干什么的？它是用来接收“不符合上述任何条件”的数据的。
实战中的坑： 你设置了 3 个条件端口，却忘了设置 Default 端口。结果，那些符合条件的数据跑对了，但有一小部分数据因为格式微差（比如多了个空格）没匹配上，直接在 Switch 节点“消失”了。
在 n8n 的运行日志里，你会看到这部分数据的状态是“Waiting”，或者直接被丢弃。这在处理大批量数据时是致命的，因为你根本不知道丢了多少。
解决方案： 永远给 Switch 节点接上一个 Default 输出口。哪怕你暂时不处理这些异常数据，也请把它导向一个 Logger 节点或者简单的 Email 通知，至少要让你知道：“嘿，有条数据没匹配上，快来看看！”
Output 顺序陷阱：自上而下的执行逻辑
Switch 节点的输出口是可以拖拽排序的。但 n8n 的处理逻辑是：从上到下依次判断。
假设你有两条规则：
- 如果金额 > 100，走端口 1
- 如果金额 > 50，走端口 2
如果你把 “> 100” 放在了 “> 50” 的下面，那么当金额是 200 时，它会先匹配到 “> 50”，直接流进了端口 2，根本不会去检查下面的 “> 100”。
笔者的经验： 这是一个典型的逻辑优先级问题。在设置 Switch 时，请务必把最严格的条件放在最上面，最宽松的条件放在最下面（或者 Default）。这就像剥洋葱，先剥最外层的皮是不行的，得先挑最紧要的。
数据流的“原样”与“改写”
Switch 节点本身不改变数据，它只负责分流。但很多新手在这里会犯迷糊：为什么我的数据流到下一个节点后，JSON 格式变了？
其实，变的不是 Switch，而是你接在 Switch 后面的节点。比如你在 Switch 的某个分支后接了一个 Set 节点，试图修改数据，但忘记勾选 “Keep Only Set” 还是 “Set Everything”。
更深层的坑在于：如果你在 Switch 的不同分支里对同一个字段进行了不同的操作，最后汇总时（如果后面有 Merge 节点），数据的一致性就会被破坏。
硬核建议： 在多路分流的架构中，尽量保持 Switch 之后各分支的“纯净度”。如果不同分支需要的数据结构差异巨大，建议在 Switch 之前就做好数据快照（使用 Set 节点保存原始数据），或者在分支处理完后，重新整理数据结构再进行后续操作。
FAQ：Switch 节点常见问题答疑
Q1：Switch 节点能处理“或”的逻辑吗？（例如：状态为 A 或 状态为 B）
A：当然可以。在 Expression 模式下，你可以使用 JavaScript 表达式。例如：{{ ['A', 'B'].includes($json.status) }}。这样，状态是 A 或 B 的数据都会流向该端口。
Q2：为什么我的 Switch 条件明明是 true，数据却走了 Default 端口？
A：这通常是因为数据类型不匹配。比如你的条件是 {{ $json.id == 123 }}，但实际数据里 id 是字符串 “123”。在 n8n 的某些版本中，强类型检查可能会导致这种问题。建议在 Console 打印一下数据类型，或者使用 {{ parseInt($json.id) == 123 }} 来处理。
Q3：Switch 节点后面接 HTTP Request，如果其中一个请求失败了，整个流程会停止吗？
A：不会。n8n 的流程是并行处理的。如果一个分支报错，它只会影响该分支的后续节点，其他分支会继续运行。但如果你在 HTTP Request 节点开启了 “Stop On Error”，那该分支就会停止。建议根据业务需求谨慎设置错误处理策略。
总结与资源
Switch 节点看似简单，实则决定了你的自动化流程是否健壮。它不仅仅是数据的分流器，更是逻辑的守门员。
记住 N8N大学 的核心理念：自动化不是为了炫技，而是为了稳定地解决问题。 在复杂的多路分流场景中，多花 5 分钟测试边界条件，能为你节省数小时的排错时间。
如果你在 n8n 的使用中遇到了棘手的报错，或者有想实现的复杂逻辑，欢迎访问我们的官网 n8ndx.com，这里有更多硬核的实战案例和社区支持。避坑，我们是认真的。
