Connection必须单例复用、Channel不可跨线程共享、发布必须经Exchange路由——否则高并发下易触发too_many_connections、channel阻塞或消息丢失。
连接不能每次发消息都 new，channel 不能跨线程复用，发布/订阅必须用 exchange —— 这三点不落实，代码跑得越快，线上崩得越准。
Connection 必须单例复用，否则 TCP 握手压垮 Broker
常见错误是每次发送都 new ConnectionFactory().CreateConnection()，发完立刻 Close()。这会导致每秒几十次 TCP 三次握手，RabbitMQ 默认会主动断连（connection_closed_by_broker），日志里满屏 too_many_connections 或 connection timeout。
- 正确做法：用
Lazy<iconnection></iconnection>或 DI 容器注册为 Singleton，全局只一个IConnection -
IConnection是线程安全的，但IModel（即 channel）不是——每个业务操作（如一次 HTTP 请求）必须新建IModel，用完立即Dispose() - 不要手动调
channel.Close()，using块自动释放即可；若提前释放失败，model.IsOpen为false时再发消息会抛AlreadyClosedException
发布（Publish）必须走 Exchange，不能直写 Queue
“发布/订阅”模式本质是 fanout、topic 或 direct 类型的 exchange 路由，不是往某个 queue 里硬塞数据。直接 BasicPublish("", "queue_name", ...) 是点对点临时队列，不支持多消费者订阅。
- 声明 exchange：用
channel.ExchangeDeclare("order.topic", "topic", durable: true)，类型选topic才能按 routing key 匹配 - 绑定 queue 到 exchange：每个订阅方需先
channel.QueueDeclare("order_handler_a", ...)，再channel.QueueBind("order_handler_a", "order.topic", "order.*") - 发布时 routing key 必须匹配：如
BasicPublish("order.topic", "order.created", ...)，才能被order.*绑定的 queue 收到
订阅（Consume）必须用异步消费者，避免 channel 阻塞
用 EventingBasicConsumer + 同步回调是陷阱：一旦回调里有 await 但没写 async void，或异常未捕获，channel 就卡死，后续消息全积压，CPU 占满却无日志。
- RabbitMQ.Client v6.0+ 推荐
AsyncEventingBasicConsumer，它原生支持async/await回调 - 务必控制预取数：
channel.BasicQos(0, 10, false)，防止一个消费者堆积几百条消息吃光内存 - Nack 时设
requeue: false，让失败消息进 DLX（dead-letter exchange），而不是无限重试拖垮系统 - 示例关键行：
ch.BasicAck(ea.DeliveryTag, multiple: false)和ch.BasicNack(ea.DeliveryTag, multiple: false, requeue: false)必须成对出现
消息体序列化要统一，别在 consumer 里反序列化失败才报错
生产者发的是 JSON 字节数组，消费者却用 Encoding.UTF8.GetString() 直接转字符串再手动 JsonSerializer.Deserialize<t>()</t>，一旦字段名错、类型不匹配，就抛 JsonException 导致消息被 Nack 丢弃——而你根本不知道是哪条丢了。
- 建议：生产者发前用
System.Text.Json序列化并加版本头（如{"v":"1.0","data":{...}}） - 消费者先检查 header 再解析 body，解析失败统一走 DLX，不 throw
- 不要依赖
BasicProperties.ContentType做分发逻辑，它只是提示，不强制校验
最易忽略的是 exchange 类型和 binding key 的语义一致性：topic exchange 的 routing key 用点分隔、支持 * 和 #，但如果你绑的是 order.# 却发 payment.created，那这条消息就彻底消失，连 dead-letter 都进不去——因为根本没路由到任何 queue。
