c#调用rabbitmq的核心是保障消息不丢失、不重复、不卡死：需检查erlang与服务状态，确保exchange/queue/binding匹配，启用confirm模式+persistent标志，消费者禁用autoack并显式ack，异步消费须避免在eventingbasicconsumer中直接await。
直接上结论：C# 调用 RabbitMQ 的核心不是“怎么连上”，而是“怎么不丢消息、不重复消费、不卡死连接”。只要绕过这三关，剩下的就是参数微调和场景适配。
连接失败或 ConnectionFactory 报超时，先查 Erlang 和服务状态
RabbitMQ 启动依赖 Erlang 运行时，Windows 上常见错误是 Operation timeout 或 Connection failed: no connection could be made。这不是 C# 代码问题，而是底层没跑起来。
- 打开命令行，执行
erl -version，确认 Erlang 已正确安装且ERLANG_HOME和Path都配置对了 - 运行
services.msc，检查RabbitMQ服务是否为“正在运行”——它默认不随系统自启 - 若服务启动失败，去
C:\Users\{user}\AppData\Roaming\RabbitMQ\log看rabbit@{hostname}.log，90% 是端口被占（默认 5672）或磁盘空间不足
BasicPublish 发出去但消费者收不到，重点看 Exchange/Queue/Binding 是否匹配
消息“发了等于没发”，多半是路由断在 Exchange 到 Queue 这一环。AMQP 不会报错，只是静默丢弃。
- 确保生产者声明的
Exchange名称、类型（如Direct）、RoutingKey，和消费者绑定时用的完全一致——大小写、空格、下划线都算不同 - 消费者必须显式调用
queueDeclare，不能只靠生产者声明；否则队列不存在，绑定就无效 - 用 RabbitMQ 管理界面（
http://localhost:15672）实时查看：Exchanges 页面里该 Exchange 是否有 “Bindings” 行；Queues 页面里目标队列的 “Ready” 数是否随发送递增
消息偶尔重复或丢失，必须启用 Confirm 模式 + Persistent 标志
默认情况下，BasicPublish 是“发完即忘”的，网络抖动或 Broker 崩溃会导致消息蒸发；而消费者手动 Ack 前宕机，RabbitMQ 会重发，造成重复。
- 生产者端：创建
ConnectionFactory后设AutomaticRecoveryEnabled = true，再对IModel调用ConfirmSelect()，然后用WaitForConfirmsOrDie()等待 Broker 确认 - 发送时：
IBasicProperties必须设DeliveryMode = 2（即IPersistent），否则重启后队列清空，消息全丢 - 消费者端：
BasicConsume的autoAck必须为false，处理完逻辑后显式调用BasicAck；别在 try/catch 外层吞异常，否则 Nack 不触发重试
.NET 8+ 下异步消费容易卡死，async/await 不能直接套在 EventingBasicConsumer 里
EventingBasicConsumer.Received 事件回调是同步上下文，强行 await 会引发死锁，尤其在 ASP.NET Core 请求线程中。
- 正确做法：在事件回调里立即把
body和必要上下文（如DeliveryTag）打包进Task.Run或ThreadPool.UnsafeQueueUserWorkItem - 别用
async void处理 Received 事件——异常无法捕获，且无法 await 等待完成 - 如果要用
ChannelReader+BackgroundService构建更可控的消费流，需自行管理BasicAck时机，避免消息堆积在 Channel 中未确认
真正难的不是写通第一段 publish/consume，而是让整条链路在机器重启、网络分区、消费者崩溃时仍能保持语义正确——持久化、确认、重试、死信，这些开关默认都是关着的，得一行行亲手打开。
