SimpleMessageConverter 默认不安全，因依赖 JDK 原生序列化，存在反序列化任意类风险（如 CVE-2023-34050），且无法跨语言/版本兼容；它仅适用于 AMQP 基础类型，传 POJO 会触发危险序列化，生产环境必须替换为 Jackson2JsonMessageConverter 或显式加固。
SimpleMessageConverter 默认不安全，生产环境必须替换或显式加固。它依赖 JDK 原生序列化，既无法跨语言/跨版本兼容，又会在反序列化时无条件加载任意类——CVE-2023-34050 就源于此。Spring Boot 2.2+ 已默认禁用未白名单类的反序列化，但只要没配 allowed-classes 或换掉转换器，SimpleMessageConverter 仍会尝试反序列化，直接抛 ClassNotFoundException 或触发安全拦截。
为什么 SimpleMessageConverter 在 Spring Boot 中默认“危险”
它不是设计来传业务对象的，而是为 AMQP 协议层基础类型（byte[]、String）服务的。一旦你往 RabbitTemplate.convertAndSend() 里传一个自定义 POJO，它就会调用 SerializationUtils.serialize()，把类名、字段值、甚至类字节码一起打成二进制塞进 Message.body。消费者端一收到，就按 MessageProperties.contentType = "application/x-java-serialized-object" 去反序列化——前提是本地 classpath 里得有那个类；否则报 ClassNotFoundException；更糟的是，如果攻击者能控制消息内容，还能注入恶意类执行任意代码。
常见错误现象：
- 消费者启动时报
java.lang.ClassNotFoundException: com.example.order.OrderDTO，即使你确认 jar 包里有这个类 - 测试环境正常，上线后突然消费失败，日志只显示
Failed to convert message没有堆栈 - 启用
spring.rabbitmq.listener.simple.default-requeue-rejected=false后消息直接进死信队列，查不到具体原因
用 Jackson2JsonMessageConverter 替换的实操要点
这是最常用、最稳妥的替换方案，本质是把对象转成 JSON 字符串再发，彻底绕开 Java 序列化链路。但要注意几个关键点：
- 必须在 Spring 容器中声明一个
Jackson2JsonMessageConverter类型的@Bean，Spring Boot 的自动配置（RabbitAutoConfiguration）才会把它同时注入到RabbitTemplate和SimpleRabbitListenerContainerFactory - 发送端和消费端必须用同一个
MessageConverter，否则消费端用SimpleMessageConverter去解 JSON body，会直接报Cannot construct instance of java.util.LinkedHashMap类型错误 - 如果 DTO 里有
LocalDateTime等非标准类型，需提前注册JavaTimeModule，否则序列化失败
示例配置：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
@Bean
public MessageConverter jackson2JsonMessageConverter() {
Jackson2JsonMessageConverter converter = new Jackson2JsonMessageConverter();
ObjectMapper objectMapper = new ObjectMapper();
objectMapper.registerModule(new JavaTimeModule());
converter.setJsonObjectMapper(objectMapper);
return converter;
}
不换转换器，只加固 SimpleMessageConverter 的风险与限制
理论上可以保留 SimpleMessageConverter，仅通过配置白名单收紧反序列化范围，比如：
- 设置
spring.rabbitmq.listener.simple.allowed-classes=com.example.**—— 但该配置只对Jackson2JsonMessageConverter+@type多态反序列化生效，对SimpleMessageConverter无效 - 想让
SimpleMessageConverter安全，只能自己继承它并重写fromMessage()，在反序列化前校验ObjectInputStream的类名，但这已脱离 Spring AMQP 标准路径，维护成本高且容易漏掉边界 case - Spring 团队已在文档中明确建议：“Avoid using
SimpleMessageConverterfor custom domain objects”
换句话说：加固 SimpleMessageConverter 是条死胡同，不是配置问题，是机制缺陷。
最容易被忽略的兼容性陷阱
团队协作中，有人用 Jackson2JsonMessageConverter 发消息，有人还用默认 SimpleMessageConverter 消费，结果消息体是 JSON 字符串，却被当成二进制流去反序列化，报错信息极其隐晦，比如：
InvalidClassException: invalid descriptor for field-
StreamCorruptedException: invalid type code: 7B（0x7B 是{的 ASCII，说明 body 实际是 JSON）
这类问题不会在编译期暴露，只有运行时发消息才触发，且上下游日志对不上。真正要落地，必须统一团队的转换器声明方式，并在 CI 阶段检查 MessageConverter Bean 是否唯一存在。
