Content-Type 是 HTTP 请求 / 响应头中核心的字段，用来告诉服务端 / 客户端「传输的数据是什么格式」，不同取值对应完全不同的解析方式。

我会用通俗易懂的方式讲解开发中最常用的 4 种 Content-Type，以及它们的核心区别和使用场景。

一、核心结论先明确

二、逐个拆解（附示例 + 使用区别）

1. application/x-www-form-urlencoded（最基础的表单格式）

• 本质：浏览器提交表单时的默认格式，会把表单里的键值对转成 key1=value1&key2=value2 的字符串，且自动编码特殊字符（比如空格转 +、中文转 URL 编码）。
• 示例： 请求体内容：username=admin&password=123456&age=20
• 服务端接收：用 @RequestParam（对应你之前的登录接口）。
• 关键区别：
  • 只能传普通键值对，不能传文件；
  • 数据会被编码，适合简单的文本参数；
  • 是 <form> 标签不加 enctype 时的默认值。

2. multipart/form-data（文件上传专用）

• 本质：「分段」传输数据，把每个参数（普通字段 / 文件）分成独立的「部分」，每个部分有自己的标识和格式，专门解决文件上传问题。
• 示例： 请求体里会包含分隔符（比如 ------WebKitFormBoundaryxxx），区分不同参数：

  ------WebKitFormBoundary7MA4YWxkTrZu0gW
  Content-Disposition: form-data; name="username"
  
  admin
  ------WebKitFormBoundary7MA4YWxkTrZu0gW
  Content-Disposition: form-data; name="avatar"; filename="head.jpg"
  Content-Type: image/jpeg
  
  [文件二进制数据]
  ------WebKitFormBoundary7MA4YWxkTrZu0gW--

• 服务端接收：普通字段用 @RequestParam，文件用 @RequestPart("avatar") MultipartFile file。
• 关键区别：
  • 支持同时传普通参数 + 文件，是文件上传的唯一选择；
  • 数据不编码，直接传输二进制（适合文件）；
  • 传输体积比 x-www-form-urlencoded 大（因为有分隔符）。

3. application/json（前后端分离主流）

• 本质：传输标准的 JSON 字符串，是 RESTful 接口的标配，支持复杂数据结构（对象、数组）。
• 示例： 请求体内容：{"username":"admin","password":"123456","roles":["admin","user"]}
• 服务端接收：用 @RequestBody + 实体类（比如 @RequestBody LoginDTO loginDTO）。
• 关键区别：
  • 支持复杂数据结构（对象嵌套、数组），而 x-www-form-urlencoded 只能传扁平键值对；
  • 数据格式清晰，是前后端分离的首选；
  • 不能用 @RequestParam 接收（会解析失败）。

4. text/plain（纯文本）

• 本质：只传输无格式的纯字符串，服务端不会做任何解析，直接按文本处理。
• 示例：请求体内容就是 admin,123456（无键值对，纯文本）。
• 服务端接收：需手动读取请求体内容解析，几乎不用在业务接口中。
• 关键区别：无结构化，仅适合简单文本传输（比如日志、纯文本消息）。

三、核心使用原则（避坑关键）

1. 普通表单提交（无文件） → 用 application/x-www-form-urlencoded + @RequestParam；
2. 上传文件（含普通参数） → 用 multipart/form-data + @RequestParam/@RequestPart；
3. 前后端分离接口（JSON 传参） → 用 application/json + @RequestBody；
4. 不要混用：比如前端传 application/json，服务端用 @RequestParam 接收，必然报解析错误（这是新手最常见的坑）。

四、Postman 测试示例（快速验证）

总结

1. x-www-form-urlencoded 是表单默认格式，适合简单键值对，用 @RequestParam 接收；
2. multipart/form-data 是文件上传专用，支持混合传参；
3. application/json 是前后端分离主流，支持复杂结构，用 @RequestBody 接收；
4. text/plain 无结构化，极少用在业务接口中。

核心避坑点：前端传什么 Content-Type，服务端就要用对应的接收方式，比如 JSON 格式不能用 @RequestParam，表单格式不能用 @RequestBody