因为Fanout交换机语义上完全匹配广播需求：它忽略路由键、不做任何匹配，将消息无差别转发至所有绑定队列；而Topic或Direct需依赖路由键匹配，易因拼写错误、绑定遗漏或额外判断开销导致部分消费者收不到消息。
为什么直接用 Exchange 类型为 "fanout" 而不用 "topic" 或 "direct"
发布订阅模式的核心是“广播”——所有绑定到该 Exchange 的队列都无差别收到消息。只有 "fanout" 交换器类型语义上完全匹配这一行为：它不看 routing_key，也不做任何匹配逻辑，纯粹转发。用 "topic" 或 "direct" 虽然也能绕出类似效果（比如全设成相同 routing_key），但会引入不必要的路由判断开销，且容易因键名拼写、大小写或绑定遗漏导致部分消费者收不到消息。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 声明
Exchange时必须显式指定exchangeType: "fanout"，RabbitMQ 不接受空字符串或默认值 - 无需为
fanoutExchange 设置routing_key，生产者调用channel.Publish()时传空字符串""即可 - 消费者各自声明独立的、
durable: false的匿名队列（用""作为队列名），再绑定到同一Exchange，避免队列名冲突和残留
如何确保每个消费者拿到完整副本而不是共享一条消息
关键不在 Exchange 类型，而在于是否让每个消费者拥有自己的队列实例。如果多个消费者共用一个队列，RabbitMQ 默认轮询分发（Round-robin），消息只会被其中一个消费者处理；只有每个消费者连到**不同队列**，且这些队列都绑定到同一个 fanout Exchange，才能实现真正意义上的“每人一份”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 消费者启动时调用
channel.QueueDeclare("", false, true, true, false, nil)，让 RabbitMQ 自动生成唯一队列名（如amq.gen-JzTY20BRgKO-HjmUJj0wLg） - 紧接着立刻用
channel.QueueBind()将该临时队列绑定到已存在的fanoutExchange，绑定时routing_key任意（fanout忽略它），传""即可 - 不要手动指定队列名，否则多个实例会竞争同一队列，退化为工作队列模式
channel.Publish() 调用失败但没报错？检查这三点
RabbitMQ 的 Go 客户端（streadway/amqp）中，channel.Publish() 是异步发送，返回 error 仅表示 AMQP 协议层拒绝（如 Exchange 不存在），但不保证消息已落地或被消费。常见“看似成功实则丢消息”的原因：
- Exchange 未提前声明：必须在
Publish()前调用channel.ExchangeDeclare()，且noWait: false（默认），否则服务端可能还没创建完成就发消息 - 未启用 Publisher Confirms：若需确认消息已入队，应在
channel上调用channel.Confirm(false)，再监听channel.NotifyPublish()返回的确认信号 - 连接意外中断：
Publish()返回nil只代表发出了，不代表网络可达。需结合连接健康检查（如channel.NotifyClose()）和重试逻辑
消费者退出时要不要手动删除队列
取决于队列声明时的参数。如果用了 autoDelete: true（即 QueueDeclare(..., true, ...)），且没有其他消费者绑定，RabbitMQ 会在最后一个消费者取消订阅后自动清理队列；但如果用了 durable: true，队列会持久化到磁盘，不手动删就会一直残留。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 开发/测试环境一律用
autoDelete: true+durable: false，配合随机队列名，避免脏数据堆积 - 生产环境若需队列跨重启存活，才设
durable: true，但此时必须配套管理生命周期——例如在应用 shutdown hook 中显式调用channel.QueueDelete() - 不要依赖消费者进程退出自动清理：Go 程序崩溃、OOM、K8s 强制 kill 都不会触发 defer 或 cleanup 逻辑
