fanout广播模式无需routingkey，但交换机与队列名称必须严格一致且大小写敏感；声明时需显式设durable=true、autodelete=false，yaml不支持自动声明，binding须确保exchange和queue已初始化，发送时必须指定exchange名且routingkey为空字符串。
Fanout 广播模式不需要 routingKey，只要队列绑定了同名 Fanout 交换机，消息就会自动复制到所有绑定队列——但配置错一个名字或顺序，消息就静默丢失，连错误日志都不报。
fanoutExchange 声明时必须显式指定 durable = true
默认构造的 FanoutExchange 在 Spring AMQP 中是 non-durable 的（即 new FanoutExchange("fanoutExchange") 等价于 new FanoutExchange("fanoutExchange", false, false)）。RabbitMQ 重启后，这个交换机会消失，后续生产者发消息时因找不到交换机而直接丢弃，且 rabbitTemplate.convertAndSend() 不抛异常，只默默失败。
- 务必写成
new FanoutExchange("fanoutExchange", true, false) -
durable = true保证交换机持久化，autoDelete = false防止无消费者时被自动删除 - 如果用 YAML 配置（如
spring.rabbitmq.template.exchange），它不支持 Fanout 类型的自动声明，必须靠 Java Config 显式定义 Bean
queueDeclare 时 durable 和 autoDelete 要匹配业务生命周期
动态用户场景（如会议邀请）中，队列不该永久存在；但服务重启后若队列丢失，新上线用户就收不到历史广播。这里的关键是区分「临时会话队列」和「常驻处理队列」：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 用户级队列建议设为
autoDelete = true，由消费者启动时声明（如channel.queueDeclare()返回的匿名队列），断连即删，避免堆积 - 服务级队列（如日志归档、短信分发）必须设
durable = true，否则重启后绑定失效，消息进黑洞 - 注意：Spring 的
@Queue注解里autoDelete = "true"是字符串，不是布尔值，写错会导致容器启动失败
binding 必须在 queue 和 exchange 都存在之后执行
Spring Boot 启动时 Bean 创建顺序不可控。如果 Binding Bean 依赖的 Queue 或 FanoutExchange 尚未初始化，绑定会静默失败——你看到的是“没报错但收不到消息”。
- 用
@Bean+@Qualifier显式注入依赖，例如：Binding binding(Queue q, FanoutExchange e) - 避免在
@PostConstruct里手动调用channel.queueBind()，容易触发连接未就绪异常 - 验证是否绑定成功：登录 RabbitMQ Management UI，进入 Exchange 页面，点开你的
fanoutExchange，看 “Bindings” 列表里是否有目标队列
rabbitTemplate.convertAndSend() 的参数不能省略 exchange 名称
常见误写：rabbitTemplate.convertAndSend("", "", msg) 或 rabbitTemplate.convertAndSend(msg)——这会走默认交换机（AMQP default direct exchange），完全绕过你的 Fanout 逻辑。
- 正确调用必须传入 exchange 名：
rabbitTemplate.convertAndSend("fanoutExchange", "", msg) - 第二个参数 routingKey 强制为空字符串
""，不是null，否则部分版本会 NPE - 如果使用
@RabbitListener绑定队列，确保@QueueBinding中的exchange = @Exchange(type = ExchangeTypes.FANOUT)显式声明类型，否则默认是 direct
最易忽略的一点：Fanout 模式下，交换机名称大小写敏感、空格敏感、甚至末尾换行符都会导致绑定失败。线上排查时，先比对 Management UI 里显示的 exchange name 和代码里写的是否一字不差，比加日志还快。
