Spring Boot消费者用String接收Node.js发来的JSON消息会报错，因Jackson将{"..."}识别为JsonToken.START_OBJECT而非字符串字面量；正确方式是改用byte[]、Message原生接收或禁用Jackson介入。
Spring Boot 消费者用 String 接收 Node.js 发来的 JSON 消息，十有八九会报 Cannot deserialize value of type `java.lang.String` from Object value (token `JsonToken.START_OBJECT`) ——这不是 Spring Boot 的 bug，而是 Jackson 在严格执行类型契约。
为什么 String 参数在 Spring AMQP 里不等于“原样读字节”
当你声明 @RabbitListener 方法参数为 String，且项目中配置了 Jackson2JsonMessageConverter（常见于 Spring Boot 自动装配），框架就会尝试把消息体反序列化成 String 类型。但 Jackson 看到的是 {...} 开头的 JSON 对象，它只认得 "hello" 这种纯字符串字面量，遇到花括号就直接拒绝。
关键点在于：String 在这里不是“原始 payload 容器”，而是要参与 Jackson 反序列化的正式目标类型。
- Node.js 发送的是
{"id":123,"name":"foo"}（application/json） - Spring Boot 启用了
Jackson2JsonMessageConverter - 消费者方法写的是
public void handle(String body) - 结果：Jackson 尝试把 JSON object 解析成
String→ 失败
正确接收 JSON 字符串的三种实操方式
目标是让 Spring Boot 把整段 JSON 当作原始字符串拿过来，跳过 Jackson 的结构解析。
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 把参数类型换成
byte[]：Spring AMQP 对byte[]有特殊处理逻辑，不会走 Jackson，直接返回原始字节，再用new String(bytes, StandardCharsets.UTF_8)转换 - 用
org.springframework.amqp.core.Message原生接收：调用message.getBody()拿到byte[]，同样可转字符串，还能访问message.getMessageProperties().getContentType()做校验 - 禁用 Jackson 对该方法的介入：在方法上加
@Payload(required = false)并配合Message，或干脆不加@Payload，让 Spring 绕过 converter 直接注入原始 Message 实例
如果必须用对象接收，类型声明必须匹配 JSON 结构
Node.js 发的是 {"userId":1001,"action":"login"}，那 Spring Boot 就不能用 String，也不能用 Map（除非你确定字段名和类型完全可控）。
- 推荐定义一个轻量 DTO，比如
LoginEvent，字段名、类型、getter/setter 齐全 - 确保 Node.js 和 Java 的字段命名策略一致（如都用 camelCase，或统一配 Jackson 的
@JsonProperty） - 避免用
Map<String, Object>：它对嵌套结构、数字类型推导不稳定，容易在深层字段上反序列化失败 - 若字段动态多变，可用
com.fasterxml.jackson.databind.JsonNode：它是 Jackson 的通用 JSON 树模型，能安全承载任意结构
跨语言场景下最容易被忽略的 contentType 和编码
Node.js 发送时没设 contentType，或设成了 text/plain，而 Spring Boot 的 Jackson2JsonMessageConverter 默认只处理 application/json。这时即使 JSON 内容合法，converter 也可能被跳过，降级到 SimpleMessageConverter，导致反序列化路径错乱。
- Node.js 端务必显式设置
contentType: 'application/json'（RabbitMQ message properties） - Spring Boot 端检查是否启用了全局
Jackson2JsonMessageConverterbean，而不是依赖自动配置的模糊匹配 - UTF-8 编码必须两端一致；Node.js 用
Buffer.from(jsonStr, 'utf8')发，Java 端别用系统默认编码解 - 测试时用
curl -X POST ... --data-binary @msg.json手动发一条原始消息，验证 broker 中存的内容是否符合预期
真正麻烦的不是怎么写代码，而是两端对“JSON 消息”这件事的理解偏差：Node.js 认为发的是字符串，Spring Boot 却把它当结构体来验。跨语言联调里，契约比实现更早失效。
