Spring Boot 中 HTTP 415 错误本质是客户端 Content-Type 与服务端 consumes 契约不匹配，需检查请求头、@RequestBody 注解、Jackson 配置及 JSON 结构，并用 @ControllerAdvice 统一友好提示。

Spring Boot 中遇到请求媒体类型异常（比如 HttpMediaTypeNotSupportedException 或 HTTP 415 错误），本质不是代码没跑通，而是客户端发来的数据“敲错了门”——服务端标着只收 JSON，结果收到表单格式；或者标着只收 XML，却送来纯文本。问题不在逻辑，而在契约不匹配。

检查客户端 Content-Type 请求头

这是最常见也最容易忽略的一环。Spring 严格依据请求头中的 Content-Type 决定用哪个 HttpMessageConverter 去解析请求体。

• 用浏览器 DevTools 的 Network 面板或 curl -v 确认实际发出的请求头是否包含 Content-Type: application/json
• Postman 中不能只选 Body → raw → JSON，必须手动在 Headers 里显式添加 Content-Type: application/json
• 避免同时存在多个 Content-Type 头，或出现 text/plain、application/x-www-form-urlencoded 等冲突类型

核对控制器方法的 consumes 和 @RequestBody

Spring 控制器方法需要明确声明它“愿意接收什么”，并配合正确的注解才能触发 JSON 反序列化。

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。 术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

• 如果方法用了 @RequestBody，但没写 consumes，默认接受所有类型；但若写了 consumes = "application/json"，就必须匹配
• 确保参数前加了 @RequestBody —— 没它，Spring 默认按表单（@RequestParam）或查询参数解析，不会尝试 JSON 反序列化
• 禁止混用 @RequestBody 和 @RequestParam 接收同一请求的主体数据，这会导致解析策略冲突

确认 Jackson 依赖和配置可用

即使头和注解都对，如果 JSON 解析器本身不可用，也会退回到 415。

• 检查项目是否引入了 spring-boot-starter-web（它自动带 jackson-databind）
• 若自定义了 ObjectMapper Bean，需确认未禁用 DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES 等导致反序列化提前失败的设置
• 请求体 JSON 结构要与目标 Java 类字段名、类型、可空性一致；例如传了字符串给 int 字段，可能先报 400，但某些配置下也可能被拦截为媒体类型不支持

统一捕获并友好提示 415 异常

即便排查到位，前端仍可能因版本更新或配置遗漏发错请求。建议用全局异常处理器兜底，把技术错误转成可读提示。

• 用 @ControllerAdvice + @ExceptionHandler(HttpMediaTypeNotSupportedException.class)
• 返回标准 JSON 响应，含状态码 415、明确 message（如“请求格式不支持，请使用 application/json”）、甚至建议的 Content-Type 示例
• 避免直接暴露堆栈或内部类名，防止信息泄露