switch节点按priority字段路由通知至不同中间件：high→kafka/redis、medium→rabbitmq、low→postgresql/watermill，需统一字段名与值、适配各队列格式要求，并验证全路径匹配与容错。

用 switch 节点处理通知优先级，核心是把“优先级字段”作为路由依据，再按级别分发到对应中间件队列。这不是单纯配个条件，而是要打通数据结构、路由逻辑和下游写入三环。

明确通知里的优先级标识

确保每条通知消息体中包含可识别的优先级字段，比如：
• 字段名统一为 priority（推荐）或 urgency
• 值为字符串或数字：如 "high"、"medium"、"low"，或 0、1、2
• 避免空值或模糊值（如 "maybe"、"soon"），否则 Switch 无法稳定匹配

在 Switch 节点中配置多级路由规则

以 n8n 的 Switch 节点为例，启用 Rules 模式，逐条添加分支：

Switch Modes

动态切换AI模型以优化成本与性能。当用户发出“eco mode”、“balanced mode”、“smart mode”或“max mode”等模式指令，或使用“/modes status”查询状态及“/modes setup”配置模式时触发。

下载

• High 分支：条件设为 priority 等于 "high" → 连接 Kafka 或 Redis Stream 队列（低延迟、强实时）
• Medium 分支：条件设为 priority 等于 "medium" → 接入 RabbitMQ 普通队列（支持重试+死信）
• Low 分支：条件设为 priority 等于 "low" → 写入 PostgreSQL 延迟表 或 Watermill 的 delayed-requeue 队列
• 兜底分支：启用 “No match” 备选输出，记录异常通知到日志服务或告警通道

对接不同中间件时的关键适配点

各队列对消息格式、元数据要求不同，不能直传原始 payload：

• Kafka：需补全 headers，例如 "x-priority": "high"，便于消费者做快速判断
• RabbitMQ：建议用 routing key 区分优先级，如 notify.high、notify.medium
• Watermill：优先级需转为 delay 参数，例如 high → delay=0s，low → delay=5m
• 若用 WNS（Windows 通知），则映射为 X-WNS-Priority: high/medium/low 标头

验证与容错建议

上线前重点检查三点：

• 用测试消息覆盖所有 priority 取值，确认每条都进对队列，不漏不串
• 模拟高并发场景下 low 优先级消息是否被 medium/high 挤压（尤其 RabbitMQ 未开启优先级队列插件时）
• 设置每个分支的失败重试策略：high 分支建议最多 1 次重试 + 立即告警；low 分支可设 3 次指数退避