MassTransit 是对 RabbitMQ 等中间件的抽象封装，不自带消息存储能力；必须先运行 RabbitMQ 服务，正确配置连接字符串、virtualHost、ConfigureEndpoints，并启用手动确认与重试机制以保障可靠性。
MassTransit 是 C# 生态中成熟度高、生产就绪强的消息总线库，它本身不是消息中间件，而是对 RabbitMQ、Kafka、Azure Service Bus 等底层传输的抽象封装。直接用它“实现中间件”是误解——你真正要做的是：在已有消息中间件（如 RabbitMQ）之上，用 MassTransit 构建可维护、可观测、支持重试/死信/事务的消息通信层。
为什么不能跳过 RabbitMQ 直接用 MassTransit？
MassTransit IBus 实例必须绑定到一个真实传输（transport），比如 RabbitMqTransport。它不自带存储或队列能力，也不监听端口、不管理连接池。常见错误是只装了 MassTransit 和 MassTransit.RabbitMQ，却没启动 RabbitMQ 服务，结果 bus.StartAsync() 卡住或抛出 BrokerUnreachableException。
- 本地开发时，必须先运行 RabbitMQ（推荐用 Docker：
docker run -d -p 5672:5672 -p 15672:15672 rabbitmq:3-management） - 连接字符串里不能漏掉
virtualHost（默认是/），否则会报Operation failed: Connection failed -
UseRabbitMq()后必须调用ConfigureEndpoints()，否则消费者不会自动绑定到对应队列
如何正确注册消费者并保证消息不丢失？
MassTransit 默认启用「自动确认」，但这是危险的——如果消费者处理中途崩溃，消息就丢了。真正在意可靠性，得显式配置 prefetchCount 和手动 Ack。
- 在
ConfigureConsumerEndpoint中设置e.UseMessageRetry(r => r.Interval(3, 1000))控制重试次数与间隔 - 用
e.DeadLetterQueue("myapp-dlq")指定死信队列，避免无限重试拖垮系统 - 消费者类必须实现
IConsumer<T>，且方法签名只能是Task Consume(ConsumeContext<T> context)；加额外参数（如ILogger）会导致 DI 解析失败 - 若消息体含复杂嵌套对象，确保序列化器一致：默认用 System.Text.Json，但 RabbitMQ 里存的是 JSON 字节流，接收端反序列化失败时只会静默丢弃（无日志）
怎么调试消息没被消费的问题？
最常遇到的现象是：生产者发了消息，RabbitMQ 管理界面能看到 Exchange 有流量、Queue 有堆积，但消费者日志完全空白。这不是 MassTransit 的 bug，而是拓扑没对齐。
- 检查消费者注册是否用了
AutoStart = true，否则IBus不会自动启动监听 - 确认消费者类名和命名空间是否和
ConfigureEndpoints()推导出的队列名一致（默认为[Namespace].[ClassName]，比如MyApp.Consumers.OrderCreatedConsumer→ 队列名myapp_consumers_ordercreatedconsumer） - 用
bus.GetProbeResult()输出诊断信息，重点关注transport下的healthy字段和receiveEndpoint的ready状态 - 临时关闭消费者自动绑定，手动声明队列并绑定到 Exchange：
channel.QueueBind(queueName, exchangeName, routingKey)，排除 MassTransit 自动配置干扰
跨服务共享消息契约要注意什么？
多个服务共用同一份消息类型（如 OrderCreated）时，看似省事，实则埋雷。MassTransit 要求所有服务使用**完全相同的程序集版本号 + 类型全名**做反序列化，否则会抛 SerializationException 或静默失败。
- 不要把消息类型定义在某个业务服务的私有项目里，应抽成独立 NuGet 包（如
MyApp.Contracts），语义化版本发布 - 避免在消息类里用
DateTime字段，改用DateTimeOffset，防止时区解析歧义 - 若必须兼容旧版字段，给属性加
[DataMember(Order = 1)]并保持Order值不变；移除字段时不要删，改为[Obsolete]+ 注释说明 - 升级契约前，务必先上线新消费者（兼容双版本反序列化），再下线旧生产者，严禁反向操作
Ready/Unacked 数值，再比对 bus.GetProbeResult() 输出。多数“收不到消息”的 case，本质是 transport 层没通，而不是业务逻辑错了。 
