fanout交换机发不出消息的根本原因是绑定未生效或消费者未正确声明并绑定队列；其广播机制依赖队列与交换机的显式绑定，且routing key必须为空字符串，队列名须唯一以确保真正广播。
为什么 Fanout 交换机发不出消息？
根本原因通常是绑定没生效，或者消费者没正确声明队列并绑定到交换机。Fanout 不看 routing key，只靠绑定关系广播——没绑定，就等于没订阅。
- 检查是否在消费者端调用了
channel.queueBind()，且参数顺序是(queueName, exchangeName, "")；空字符串是必须的，不能省略或填任意值 - 确认交换机和队列都已声明：
channel.exchangeDeclare()和channel.queueDeclare()必须在queueBind()之前执行 - 生产者发消息时，
channel.basicPublish(exchangeName, "", props, body)的 routing key 必须为空字符串（不是 null，也不是 "default"）
多个消费者收不到同一条消息？
这是最常见的误解：Fanout 是「广播」，但前提是每个消费者用的是**不同队列名**。如果所有消费者都连同一个队列，RabbitMQ 会轮询分发，变成负载均衡，不是广播。
- 每个消费者启动时，应调用
channel.queueDeclare()且不传 queueName（让服务端自动生成唯一队列），或显式传入不同名字，比如"subscriber-a"、"subscriber-b" - 不要复用队列名，也不要设置
durable=false后还硬编码队列名——重启后队列消失，绑定丢失，广播就断了 - 如果你需要“上线即收历史消息”，得开启队列持久化 + 消息持久化，并确保消费者在发布前已声明并绑定好队列
Spring Boot 里用 @RabbitListener 怎么配 Fanout？
Spring AMQP 默认走 Direct 语义，直接加 @RabbitListener 不会自动绑定到 Fanout 交换机，必须手动声明交换机、队列和绑定关系。
- 在配置类里声明
Exchange：用new FanoutExchange("my.fanout")，别用DirectExchange - 每个监听器对应一个独立
Queue实例（不能共用），再用BindingBuilder.bind(queue).to(fanoutExchange)绑定 -
@RabbitListener(queues = "queue.name")中的 queue 名必须和你声明的Queuebean 名或实际队列名一致；大小写、拼写错一个字符，就收不到 - 避免用
@EnableRabbit自动声明却漏掉绑定逻辑——Spring 不会替你猜你要广播
消息发出去了，但有的消费者延迟几秒才收到？
不是 Fanout 本身慢，而是 RabbitMQ 在等待 TCP 确认、消费者预取（prefetch）设太高，或消费者处理太慢导致 channel 堵塞。
- 检查消费者端
prefetchCount：设成1（如container.setPrefetchCount(1)）能减少积压，但别设成0——那是无限制，反而更易卡住 - 确认消费者没有在
@RabbitListener方法里做耗时同步操作（比如 HTTP 调用、大文件写入），这会让 channel 卡住，后续消息排队 - 网络层面：如果消费者分布在不同机房，DNS 解析慢、TCP 连接重建频繁，也会表现为“广播不同步”——这时要查
netstat和 RabbitMQ 的connection列表，看连接状态是否稳定
Fanout 广播真正难的不是配置，而是让每个消费者都拥有“独立队列+可靠绑定+及时响应”的闭环。少一个环节，看起来就像功能失效。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
