RabbitMQ发布/订阅模式必须使用fanout交换器，生产者发消息到交换器而非队列，消费者通过临时队列绑定该交换器实现广播消费；硬编码交换器名如“logs”会导致多服务消息污染、无法灰度、运维混乱，应按业务域命名并配置化管理。
直接说结论：用 RabbitMQ.Client + ExchangeDeclare 声明 fanout 交换器，再配合临时队列（queueDeclare 不传名字）+ 自动解绑，才是生产环境里真正可靠、可扩展的发布/订阅实现方式。
为什么不能直接复用示例里的 "logs" 固定交换器名
硬编码交换器名（比如 "logs"）在开发阶段看着省事，但上线后会立刻暴露问题：
- 多个服务共用同一交换器时，消息互相污染——A服务发的“订单创建”被B服务的消费者误收
- 无法做灰度发布：你没法让新版本消费者只接收部分流量，因为所有绑定都指向同一个交换器
- 运维排查困难：控制台里看到一堆叫
"logs"的交换器，根本分不清归属哪个微服务 -
ExchangeDeclare的durable参数若设为false（默认），RabbitMQ 重启后交换器消失，但消费者代码没做重连兜底，直接静默失败
正确做法是按服务/业务域命名，例如 "order-service-events"，并统一在配置中心或 appsettings.json 中管理。
fanout 交换器下，队列必须手动声明吗
必须。即使你只想广播消息，也得先有队列才能绑定。但关键在于：别写死队列名。
- 用
channel.QueueDeclare()不传queue参数（即传""），RabbitMQ 会生成随机唯一队列名，如amq.gen-Jk87xL2vQaX9zYn1tRwFgA，适合单次监听场景 - 如果需要持久化或跨重启恢复消费，才显式传入有意义的队列名（如
"order-notify-consumer-v2"），同时设置durable: true - 绑定时必须调用
QueueBind，且routingKey对fanout无效，填空字符串即可：channel.QueueBind(queue: myQueue, exchange: "order-service-events", routingKey: "") - 忘记
QueueBind是常见错误——消息进了交换器，但没队列收，日志里完全静默，监控也看不到积压
消费者如何避免消息丢失或重复消费
fanout 本身不保证顺序和恰好一次，靠客户端行为补足：
- 开启手动确认：
channel.BasicQos(prefetchSize: 0, prefetchCount: 1, global: false)+autoAck: false在BasicConsume里，否则网络断开时消息直接丢弃 - 处理完业务逻辑再调
channel.BasicAck；出异常时根据策略选BasicNack（重试）或丢进死信队列 - 不要在
EventingBasicConsumer的HandleDelivery里直接写耗时操作（如 HTTP 调用），应投递到本地线程池或Task.Run，否则阻塞整个通道，后续消息卡住 - 消费者启动时，建议先
channel.QueuePurge清空旧消息（仅限测试/灰度环境），避免脏数据干扰
连接和通道生命周期怎么管才不出错
很多人把 IConnection 和 IModel 当成一次性对象，这是高并发下的性能杀手和内存泄漏源：
-
IConnection应全局单例（.NET Core 推荐注册为Singleton），它内部维护 TCP 连接池，频繁新建会打满 socket -
IModel（即channel）是轻量级对象，但**不能跨线程共享**，每个消费者/发布者操作必须用自己connection.CreateModel()出来的实例 - 用
using包裹IModel是安全的，但别包裹IConnection——Dispose会关底层连接 - 网络中断时，
IConnection不会自动重连，需监听connection.ConnectionShutdown事件，触发重建逻辑
最易被忽略的一点：RabbitMQ 默认对单个连接限制 1024 个 channel，如果你在循环里反复 CreateModel() 又不释放，很快触发 command invalid 错误，而错误堆栈根本不提 channel 数量超限。
