声明主交换机时必须在exchange_declare中通过arguments显式传入alternate-exchange参数，且备份交换机须预先存在并绑定队列；ae仅捕获路由失败，不处理队列满、ttl过期等后续丢弃。
声明主交换机时必须传 alternate-exchange 参数
备份交换机不是独立功能，而是主交换机的一个声明属性。你不能事后给已存在的交换机“加”上 alternate-exchange；它必须在调用 exchange_declare（Python）或 channel.exchangeDeclare（Java）时，通过 arguments 显式传入。否则 RabbitMQ 会完全忽略这个配置。
常见错误现象：代码里写了 args.put("alternate-exchange", "ae")，但没传进 exchangeDeclare 的最后一个参数，或者传了空 Map —— 此时 AE 不生效，未路由消息依然静默丢失。
- Python（pika）必须这样写：
channel.exchange_declare(exchange='main', exchange_type='topic', arguments={'alternate-exchange': 'backup'}) - Java 必须确保
args是第 6 个参数，且非null：channel.exchangeDeclare("main", "topic", true, false, false, args) - RabbitMQ 控制台或
rabbitmqctl list_exchanges不会直接显示 AE 配置，得用rabbitmqctl exchange_info main或 HTTP API 查arguments字段
备份交换机本身必须是真实存在且可路由的
AE 不是“自动创建”的概念。你声明主交换机时指定的 backup 名字，必须对应一个**已提前声明好、且至少绑定一个队列**的交换机。否则消息会被丢弃，RabbitMQ 日志里会出现 NOT_FOUND - no queue found for alternate-exchange 类似错误。
典型使用场景是：主交换机类型为 direct 或 topic，而备份交换机固定用 fanout —— 因为 fanout 不依赖 routing key，能无条件收下所有“漏网”消息。
- 必须先声明备份交换机：
channel.exchange_declare(exchange='backup', exchange_type='fanout') - 再声明队列并绑定到它：
channel.queue_declare(queue='unrouted_logs'); channel.queue_bind(queue='unrouted_logs', exchange='backup') - 不能把备份交换机设成
internal=true，否则主交换机无法向它转发消息
mandatory=True 和 alternate-exchange 别混用
两者解决的是同一类问题（未路由消息），但机制互斥。mandatory=True 会让 RabbitMQ 把消息原路返回给生产者（触发 basic.return），而 alternate-exchange 是让消息换一条路继续走。如果同时启用，RabbitMQ 优先执行 mandatory 流程，AE 不会触发。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
也就是说：启用了 AE 就不该设 mandatory=True，否则你既得不到返回通知，也收不到 AE 队列里的消息 —— 消息实际被丢弃了。
- 生产者发消息时，
basic_publish的mandatory参数应保持默认False - 如果你需要监控“哪些消息进了 AE”，应该消费
unrouted_logs队列，而不是监听 return 回调 - AE 转发时保留原始
routing_key，所以如果 AE 是direct类型，绑定时必须匹配该 key；用fanout可规避此限制
AE 不处理队列满、TTL 过期等导致的“不可达”
AE 只捕获一种失败：**交换机找不到任何匹配的绑定（binding）**。它不负责处理消息因队列满了（x-max-length）、过期（x-message-ttl）、消费者拒绝（basic.nack）或死信转发（x-dead-letter-exchange）而被丢弃的情况。
换句话说：AE 是“路由层兜底”，不是“全链路兜底”。如果你发现某些本该进 AE 的消息消失了，大概率是它们其实成功路由到了某个队列，只是在队列内部被丢弃了。
- 检查目标队列是否设置了
x-max-length或x-message-ttl，这些参数会导致消息无声消失 - AE 不会重试、不会修改消息头，转发时
delivery_mode、priority等属性全部保留 - 如果主交换机绑定了多个队列，但其中部分队列因为
auto_delete=True已被删掉，而剩余绑定又不匹配 routing key —— 这种情况 AE 才会生效
AE 的关键约束在于：它只在交换机路由决策完成的那一刻起作用，之后链路中的任何环节失效，它都管不了。真正容易被忽略的是——你以为消息“没路由出去”，其实它早就进了某个队列，只是你没监控那个队列的堆积或淘汰行为。
