FanoutExchange下convertAndSend的routingKey必须为空字符串，因其被忽略，填非空值属语义错误；声明时需显式设durable=true、autoDelete=false；多消费者需绑定不同队列才能实现广播。
为什么convertAndSend的第二个参数必须为空字符串
fanoutexchange根本不处理routingkey，传任何非空值（比如"abc"）都不会报错，但属于无效冗余——rabbitmq服务端直接忽略它。spring amqp 的 convertandsend(string exchange, string routingkey, object message) 在 fanout 场景下，routingkey 只是占位符，填空字符串 "" 是最明确、最不易引发误解的做法。
常见错误现象：有人误以为要填队列名或自定义 key，结果代码看似跑通，但后续换用 DirectExchange 时因习惯性传空串导致消息丢失，根源就在这里。
- 填
null会触发 NPE（RoutingKey参数不允许为 null） - 填任意非空字符串（如
"ignored"）能运行，但语义错误，团队协作时易误导 - 官方示例和 Spring AMQP 源码注释都明确标注 Fanout 场景下该参数“is ignored”
声明FanoutExchange时要不要指定durable和autoDelete
默认构造器 new FanoutExchange("name") 创建的是 durable=true、autoDelete=false 的交换机，符合生产环境要求。但如果你用 ExchangeBuilder.fanoutExchange(...)，就得显式控制这两个属性，否则容易踩坑。
典型问题：本地开发时用 @Bean 声明了临时交换机，但忘了设 durable=true，重启应用后交换机消失，绑定关系全丢，消费者收不到消息——因为 RabbitMQ 默认只持久化队列，不持久化交换机（除非显式声明）。
-
durable=true：交换机随 Broker 重启存活（必须开，尤其在生产环境） -
autoDelete=false：即使没有绑定队列也不会自动删除（建议关，避免队列短暂下线导致交换机被删） - Spring Boot 2.3+ 中，
FanoutExchange构造器已标记为 @Deprecated，优先用ExchangeBuilder.fanoutExchange(name).durable(true).build()
@RabbitListener绑定 Fanout 队列的两种写法差异
一种是预声明队列 + 显式绑定（通过 @Bean Binding），另一种是用 @QueueBinding 注解在监听器上动态声明。前者适合固定结构的生产环境，后者适合快速验证或临时消费场景。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
关键区别在于队列生命周期管理：用 @Bean 声明的队列由 Spring 容器托管，应用启动即创建；而 @QueueBinding 中的 @Queue 默认是 auto-delete 和 exclusive 的临时队列，消费者实例一停，队列就销毁——这在多实例部署时会导致部分节点收不到广播消息。
- 生产推荐写法：
@RabbitListener(queues = "my.fanout.queue1")，配合独立@Bean Queue声明 - 测试可用写法：
@RabbitListener(bindings = @QueueBinding(value = @Queue, exchange = @Exchange(type = "fanout", name = "logs"))) - 注意：
@QueueBinding中的@Queue若不指定name，每次启动都会生成随机队列名，无法保证重复消费同一逻辑
多个消费者同时监听同一个 Fanout 队列会发生什么
不会广播，而是竞争消费。Fanout 的“广播”只发生在交换机 → 队列层面，不是交换机 → 消费者层面。如果两个消费者都监听 test2024.fanout.queue1，那这条消息只会被其中一个消费者拿到——这是 RabbitMQ 的基本分发机制，和 Exchange 类型无关。
真正实现“所有消费者都收到同一条消息”，必须让每个消费者监听**不同的队列**，且这些队列都绑定到同一个 Fanout 交换机。这也是为什么所有教程示例里都至少声明两个队列。
- 错误理解：“起两个 @RabbitListener 监听同一个队列就能广播” → 实际是竞争消费
- 正确做法：一个 Fanout 交换机 + N 个独立命名队列 + N 个对应监听器
- 额外成本：队列数 = 消费者逻辑分支数，Fanout 本身不增加路由开销，但会增加内存和连接数占用
