Failed to load resource: 415 Unsupported Media Type 错误原因？

Question

**问题：前端发送JSON数据时出现“Failed to load resource: 415 Unsupported Media Type”错误的原因是什么？** 当浏览器发起请求时，服务器返回“415 Unsupported Media Type”错误，通常是因为请求头中缺少或错误设置了`Content-Type`。例如，前端通过`fetch`或`XMLHttpRequest`发送JSON数据时，若未设置`Content-Type: application/json`，后端（尤其是Spring Boot等框架）会拒绝请求，认为媒体类型不支持。此外，某些API仅接受特定格式（如JSON），若客户端发送了表单格式数据但声明为JSON，也会触发此错误。需确保请求头与实际请求体格式一致，并符合服务端预期。

Answer 1

1. 错误现象与基础概念解析

“415 Unsupported Media Type”是HTTP协议中定义的状态码，表示服务器拒绝处理当前请求，因为请求实体的媒体类型不被服务器所支持。在前端开发中，当通过fetch、XMLHttpRequest或现代框架（如Axios）发送JSON数据时，若未正确设置请求头中的Content-Type字段，后端服务（尤其是基于Spring Boot、Express.js等强类型校验的框架）将无法识别请求体格式，从而返回415错误。

HTTP规范要求客户端在发送非默认格式的数据时明确声明其内容类型。对于JSON数据，标准的Content-Type应为application/json。若该头部缺失或设置为text/plain、application/x-www-form-urlencoded等其他值，即使请求体为合法JSON字符串，服务器也可能拒绝解析。

2. 常见触发场景与代码示例

以下列举几种典型的前端请求写法及其潜在问题：

// ❌ 错误示例：未设置 Content-Type
fetch('/api/user', {
  method: 'POST',
  body: JSON.stringify({ name: 'Alice', age: 30 })
})
.then(res => res.json())
.then(data => console.log(data));
    

上述代码虽发送了JSON字符串，但未声明内容类型，服务器可能按表单或纯文本处理，导致415错误。

// ✅ 正确示例：显式设置 Content-Type
fetch('/api/user', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ name: 'Alice', age: 30 })
})
.then(res => res.json())
.then(data => console.log(data));
    

3. 深层原因分析：服务端如何判定媒体类型

以Spring Boot为例，控制器方法常使用@RequestBody注解接收JSON对象。Spring通过HttpMessageConverter机制选择合适的转换器（如MappingJackson2HttpMessageConverter），其触发条件之一是请求头中Content-Type必须匹配application/json。若不匹配，则抛出HttpMediaTypeNotSupportedException，对应HTTP状态码415。

此外，某些API网关或中间件（如Nginx、Kong）也会进行预检，拦截不符合内容类型的请求，进一步加剧此类问题。

4. 多维度排查流程图

graph TD
            A[前端发起POST请求] --> B{是否设置Content-Type?}
            B -- 否 --> C[添加headers: {'Content-Type': 'application/json'}]
            B -- 是 --> D{Content-Type值是否正确?}
            D -- 否 --> E[修正为application/json]
            D -- 是 --> F{请求体是否为合法JSON?}
            F -- 否 --> G[使用JSON.stringify序列化]
            F -- 是 --> H[检查后端接口@RequestBody配置]
            H --> I[确认是否支持application/json]
            I --> J[查看日志定位具体异常]

5. 跨技术栈对比分析

前端库/框架	默认Content-Type	需手动设置?	典型配置方式
原生 fetch	无（空）	是	headers: {'Content-Type': 'application/json'}
Axios	application/json	否（自动设置）	axios.post(url, data)
jQuery.ajax	application/x-www-form-urlencoded	是	contentType: 'application/json'
Angular HttpClient	application/json	通常无需	自动序列化对象

6. 高级调试策略与工具建议

在实际项目中，建议结合以下手段快速定位问题：

• 使用浏览器开发者工具的Network面板，检查请求头中Content-Type字段是否存在且值正确；
• 查看请求载荷（Payload）是否为有效JSON字符串；
• 利用Postman或curl模拟相同请求，验证服务端行为一致性；
• 在Node.js后端启用日志打印中间件（如morgan），记录原始请求头信息；
• 对于Spring应用，开启DEBUG日志级别，观察DispatcherServlet和消息转换器的日志输出。

7. 安全边界与最佳实践

尽管设置Content-Type看似简单，但在大型系统集成中常因微小疏忽引发连锁故障。推荐实施以下工程化措施：

1. 封装统一的HTTP客户端，内置默认Content-Type: application/json；
2. 在CI/CD流程中加入API契约测试，验证请求头合规性；
3. 采用OpenAPI/Swagger规范定义接口，强制文档与实现一致；
4. 避免在生产环境依赖浏览器自动推测内容类型；
5. 对第三方API调用前，先通过OPTIONS预检确认支持的媒体类型；
6. 使用TypeScript约束请求参数结构，降低运行时错误概率；
7. 在网关层统一对常见媒体类型做标准化处理；
8. 监控4xx错误率，设置告警阈值及时发现异常趋势。