MassTransit 消息失败主因是 BusControl 未 StartAsync()、RabbitMQ vhost 配置错误、消费者注册时机不当；需确保总线启动后再发布、vhost 匹配且 URL 编码、ReceiveEndpoint 在启动前注册、消息类型完全一致。
MassTransit 在 C# 项目中发布消息失败、消费者不触发、连接 RabbitMQ 无报错却收不到消息——这些问题绝大多数不是框架本身有 bug，而是配置或生命周期管理踩了坑。下面直奔关键点。
BusControl 必须 StartAsync() 后才能发布消息
这是最常被忽略的初始化步骤。只调用 Bus.Factory.CreateUsingRabbitMq() 或 ConfigureServices 中注册服务，但没真正启动总线，Publish() 就会静默丢弃消息（不抛异常、也不进队列）。
-
BusControl是一个可启动/停止的状态机，未StartAsync()前处于Created状态，所有发送操作被直接忽略 - 在 .NET 6+ 的 Host 模型中，确保
IBusControl被注册为AddHostedService，否则StartAsync()不会自动执行 - 控制台程序中需显式 await：
await busControl.StartAsync(); // 缺少这行 → 消息发不出去
RabbitMQ 连接字符串和虚拟主机必须匹配
常见现象：日志显示 “Connected to broker”，但队列始终为空，GetQueues() 查不到任何消费者绑定的队列。根本原因往往是虚拟主机（vhost）配置错误。
- RabbitMQ 默认 vhost 是
/，但很多环境（尤其是腾讯云、阿里云 RabbitMQ 实例）默认创建的是/default或自定义 vhost；host=localhost:5672/vhost中的vhost部分必须 URL 编码，比如/my%2Fspace - 检查方式：用
curl -u user:pass http://localhost:15672/api/vhosts确认实际存在的 vhost 列表 - MassTransit 配置中必须显式指定：
cfg.Host("localhost", 5672, h => { h.VirtualHost("/"); h.Username("guest"); h.Password("guest"); });
消费者注册必须在 Bus 启动前完成
如果在 StartAsync() 之后才调用 busControl.ConnectReceiveEndpoint() 或 cfg.ReceiveEndpoint()，消费者不会被监听，消息进队列后直接堆积或被丢弃（取决于策略）。
- 典型错误写法：
var bus = Bus.Factory.CreateUsingRabbitMq(...);<br>await bus.StartAsync();<br>// ❌ 此时再注册 endpoint 已失效<br>bus.ConnectReceiveEndpoint("my-queue", cfg => { ... }); - 正确时机：所有
ReceiveEndpoint必须在CreateUsingRabbitMq()的配置委托内完成，或在AddMassTransit()的回调中声明 - 使用 Microsoft DI 时，消费者类型要通过
cfg.Consumer注册，而不是手动 new 实例()
消息类型必须可序列化且命名空间一致
发布端和消费端对同一消息类型的定义不一致（比如命名空间不同、类名拼写差异、缺少无参构造函数），会导致反序列化失败，消息卡在队列里不动，日志中可能只出现模糊的 “deserialization error”。
- MassTransit 默认用 System.Text.Json，要求消息类是 public、有 public set 的属性，或标记
[JsonConstructor] - 两端引用的程序集版本、命名空间、类名必须完全一致；若用
Send而非() Publish，还要确保交换器（exchange）绑定关系正确() - 调试建议：启用 MassTransit 日志到 Debug 级别，搜索关键词
Deserializing message和Failed to deserialize - 临时验证：在消费端加一个通用消费者捕获原始字节：
cfg.Consumer<rawbytesconsumer>();<br>// 在 RawBytesConsumer 中打印 body.AsString()</rawbytesconsumer>
看是否能拿到有效 JSON
真正麻烦的从来不是“怎么写”，而是“哪个环节没生效”。Bus 生命周期、vhost 权限、序列化契约——这三个地方一旦出问题，往往没有明确异常，只有沉默的失败。上线前务必用最小可运行示例单独验证这三步闭环。
