先说结论
Content-Type: application/json的本质只有一句话：
告诉服务器——“我发给你的是 JSON 格式的数据，请按 JSON 来解析。”
就这么简单。但它背后涉及的东西，比你想象的深。
它到底在干什么
HTTP 请求有两个关键部分：头（Header）和体（Body）。
Body 里装的是你要发送的数据。但问题来了——服务器怎么知道你发的是 JSON、表单、还是一张图片？
答案就是Content-Type这个头部字段。
| 值 | 含义 |
|---|---|
application/json | Body 是 JSON 字符串 |
application/x-www-form-urlencoded | Body 是表单键值对 |
multipart/form-data | Body 包含文件上传 |
text/plain | Body 是纯文本 |
所以application/json不是在描述数据"是什么"，而是在描述数据"长什么样"。
没有它会怎样
很多人觉得：我发了 JSON 过去，服务器难道看不出来？
看不出来。
服务器不会自动猜。如果你发了一段{"name":"张三"}，但没带Content-Type，服务器可能：
- 把它当纯文本处理
- 尝试用表单解析器去读，结果报错
- 某些框架直接拒绝请求（如 Spring 默认要求明确的 Content-Type）
反过来，你带了application/json，框架就知道该用 JSON 解析器，直接把字符串转成对象。
这就是它存在的全部理由：消除歧义。
实际场景里它长什么样
前端发请求（最常见）
POST /api/user HTTP/1.1 Host: example.com Content-Type: application/json {"name": "张三", "age": 28}用 fetch 写就是：
fetch('/api/user',{method:'POST',headers:{'Content-Type':'application/json'},body:JSON.stringify({name:'张三',age:28})})注意：JSON.stringify把对象转成字符串，Content-Type告诉服务器这个字符串该怎么读。两个缺一不可。
三个常见误区
| 误区 | 事实 |
|---|---|
| “只要 Body 是 JSON 格式就行，头不重要” | 服务器不会自动识别，必须显式声明 |
“application/json和text/json一样” | text/json已被废弃，标准只有application/json |
| “GET 请求不需要 Content-Type” | 正确。GET 通常没有 Body，所以不需要 |
最后
application/json是整个现代 Web API 的基石。
RESTful 接口、前后端分离、微服务通信——底层全靠这一行头部在兜底。它不性感，不复杂，但没有它，整个 HTTP 数据交换的秩序就会崩掉。
越基础的东西，越值得认真理解一次。
