最稳妥的分发方式是@RabbitListener注解在类上+多个@RabbitHandler按参数类型自动路由；方法级@RabbitListener仅绑定队列，不支持类型匹配，易导致反序列化错误和静默丢数据。
直接结论：用 @RabbitListener 注解在类上 + 多个 @RabbitHandler 方法，配合消息体类型自动路由，是最稳妥的分发方式；别依赖方法名或顺序，类型匹配才是关键。
为什么不能只靠 @RabbitListener 写在方法上？
当多个方法都标了 @RabbitListener(queues = "my_queue")，Spring AMQP 会轮询调用它们——不管消息内容是什么。你发一条 JSON，一条 Map，一条纯字符串，它可能全塞给同一个方法，后续还得手动判断 $message->getBody() 类型再分支处理，容易漏判、难维护。
常见错误现象包括：json_decode() on null、array_key_exists() on string、反序列化失败却没抛异常导致静默丢数据。
- 根本问题：方法级
@RabbitListener是“队列绑定”，不是“类型路由” - 它不看消息 body 是什么，只看有没有监听这个 queue
- 适合场景：单类型、简单转发；不适合多协议混用（比如同时收 JSON、Map、XML）
@RabbitListener 在类上 + @RabbitHandler 按参数类型分发
Spring AMQP 会根据消费者方法的**第一个参数类型**，自动匹配传入的消息 body 并做转换（需配置对应 MessageConverter）。这是真正意义上的“类型驱动分发”。
立即学习“PHP免费学习笔记（深入）”；
示例结构：
@RabbitListener(queues = "event_queue")
public class EventConsumer {
@RabbitHandler
public void handleMap(Map<String, Object> data) {
// 自动把 JSON 字符串或 byte[] 反序列化为 Map
System.out.println("Received map: " + data.get("type"));
}
@RabbitHandler
public void handleUser(User user) {
// 需提前注册 Jackson2JsonMessageConverter，且消息是合法 JSON
System.out.println("User created: " + user.getName());
}
@RabbitHandler
public void handleRawString(String raw) {
// 任何无法转成前两种类型的，兜底走这里（前提是 String 参数在最后）
System.out.println("Raw string: " + raw);
}
}
- 注意：多个
@RabbitHandler方法必须在同一类中，且类上有@RabbitListener - 参数类型必须是具体类（如
User），不能是Object或泛型擦除后类型 - 如果消息是 JSON 但字段缺失导致反序列化失败，默认会进死信队列（DLQ），不是 fallback 到
String方法
PHP 中没有原生 @RabbitHandler，得自己模拟类型路由
PHP 的 php-amqplib 是纯过程式 SDK，不提供注解或自动类型分发。你必须手动解析 $msg->body，再用 if/else 或策略模式分发。
推荐做法：
- 约定消息头（
$msg->get('type')）或 body 结构（如顶层含"msg_type": "order_created"） - 用
json_decode($msg->body, true)统一转成数组，再查['msg_type']字段 - 避免直接
unserialize()—— 不安全，且要求生产端和消费端 PHP 版本、类定义完全一致 - 性能影响：每次都要
json_decode+ 字符串匹配，比 Java 的反射匹配略重，但可控
关键陷阱：很多人把类型判断逻辑写在回调函数里，结果每个 consumer 进程都要重复加载策略类——建议提前 require 所有 handler 类，用工厂模式缓存实例。
容易被忽略的兼容性细节
消息体编码和空值处理最常出问题：
- RabbitMQ 默认不设 content-type，
$msg->body就是 rawstring，哪怕你发的是 JSON，也得自己json_decode() - 如果生产端用了
AMQPMessage::DELIVERY_MODE_PERSISTENT但没设content_type，消费端无法自动识别格式 - 空字符串
""、null、"null"字符串三者行为完全不同，JSON 解码后分别是""、null、"null"，别混用 - PHP 8.1+ 的
json_decode默认返回array，但旧版本要加第二个参数true，否则返回stdClass
复杂点在于：类型分发本身不难，难的是让所有生产者遵守同一套消息 Schema，并在 consumer 侧做好降级和监控——比如某天突然来了个新 msg_type，既没 handler 也没告警，就直接丢了。
