RabbitMQ（EasyNetQ）仅半数消息投递成功，出现无TestCommand处理器报错

针对你遇到的EasyNetQ消息处理失败、找不到TestCommand处理器的问题，直接给你几个排查和修复的关键点：

1. 强制保证消息类型的完全一致性 #

EasyNetQ是靠**消息类型的完全限定名（命名空间+类名+程序集信息）**来匹配处理器的，这是最常见的坑：

• 分别在A端发送消息前、B端注册处理器时，输出typeof(TestCommand).FullName和typeof(TestCommand).Assembly.FullName，确保两者完全一致
• 不要在A和B各自定义TestCommand，把这个类抽成独立的类库，让A、B都引用同一个类库，从根源避免类型不匹配

2. 排查处理器注册是否被意外注销 #

你怀疑处理器被移除，重点检查B端的注册逻辑：

• 处理器注册代码要放在应用启动的初始化阶段（比如ASP.NET Core的Program.cs或Startup.cs），只执行一次，不要放在请求上下文或循环里
• 检查是否有代码调用了IBus.Unsubscribe<TestCommand>()或者IBus.Dispose()，导致处理器被注销
• 确保IBus实例是单例模式，EasyNetQ的总线对象不能频繁创建销毁，否则会连带注销消费者

3. 修正序列化配置，保留完整类型信息 #

如果类型本身一致但还是匹配失败，大概率是序列化时类型标识丢失：

• 默认EasyNetQ用Json.NET序列化，若你自定义了序列化设置，可能不小心去掉了类型信息
• 显式配置序列化保留完整类型：

var bus = RabbitHutch.CreateBus("你的RabbitMQ连接字符串", x =>
{
    x.ConfigureJsonSerializer(settings =>
    {
        settings.TypeNameHandling = TypeNameHandling.All;
        return settings;
    });
});

4. 处理错误队列的消息并配置重试 #

现在失败消息都在EasyNetQ_Default_Error_Queue里，可以先手动恢复测试，同时配置重试避免直接死信：

• 用IAdvancedBus从错误队列拉取消息，修正问题后重新发送到原队列
• 配置重试策略，让失败消息先重试再进死信：

var bus = RabbitHutch.CreateBus("你的RabbitMQ连接字符串", x =>
{
    x.DefaultConsumerErrorStrategy = typeof(RetryErrorStrategy);
    x.RetryErrorStrategy(maxRetries: 3, initialInterval: TimeSpan.FromSeconds(2));
});

5. 验证消费者与队列的绑定关系 #

启动消费者后队列消息被删但无处理逻辑，可能是消费者绑定错了队列，或者有其他消费者抢消息：

• 用RabbitMQ管理面板查看目标队列的消费者列表，确认B端的消费者确实在列
• 检查A端发送消息的队列名称，和B端注册消费者时指定的队列名称是否完全一致
• 排查是否有其他测试程序或服务在消费同一个队列，导致消息被取走但没执行你的处理逻辑

内容的提问来源于stack exchange，提问作者Navid_pdp11