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 反序列化。
- 如果方法用了
@RequestBody，但没写consumes，默认接受所有类型；但若写了consumes = "application/json"，就必须匹配 - 确保参数前加了
@RequestBody—— 没它，Spring 默认按表单（@RequestParam）或查询参数解析，不会尝试 JSON 反序列化 - 禁止混用
@RequestBody和@RequestParam接收同一请求的主体数据，这会导致解析策略冲突
确认 Jackson 依赖和配置可用
即使头和注解都对，如果 JSON 解析器本身不可用，也会退回到 415。
- 检查项目是否引入了
spring-boot-starter-web（它自动带jackson-databind） - 若自定义了
ObjectMapperBean，需确认未禁用DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES等导致反序列化提前失败的设置 - 请求体 JSON 结构要与目标 Java 类字段名、类型、可空性一致；例如传了字符串给 int 字段，可能先报 400，但某些配置下也可能被拦截为媒体类型不支持
统一捕获并友好提示 415 异常
即便排查到位，前端仍可能因版本更新或配置遗漏发错请求。建议用全局异常处理器兜底，把技术错误转成可读提示。
- 用
@ControllerAdvice+@ExceptionHandler(HttpMediaTypeNotSupportedException.class) - 返回标准 JSON 响应，含状态码 415、明确 message（如“请求格式不支持，请使用 application/json”）、甚至建议的 Content-Type 示例
- 避免直接暴露堆栈或内部类名，防止信息泄露
