Content-Type是HTTP头部字段，用于声明请求或响应体的媒体类型及字符编码，指导服务器或客户端正确解析数据格式，如application/json、application/x-www-form-urlencoded、multipart/form-data等。
Content-Type 头部不是用来“告知服务器客户端的数据编码格式”的，而是告诉服务器请求体（body）中数据的媒体类型和字符编码。关键在于：它描述的是你正在发送的内容本身是什么格式，而不是客户端系统或浏览器用什么编码方式“生成”了这个内容。
Content-Type 的核心作用是声明数据格式
服务器不关心客户端内部怎么编码字符串，只依赖 Content-Type 告知的信息来决定如何解析请求体。比如：
- application/json;charset=utf-8 → 服务器按 UTF-8 解码字节流，再按 JSON 规则解析结构
- application/x-www-form-urlencoded → 服务器按 URL 编码规则（默认 ASCII 兼容，实际常隐含 UTF-8）解码键值对
- multipart/form-data; boundary=xxx → 服务器按分段边界拆分二进制块，分别处理文本字段和文件
常见场景下如何正确设置
必须匹配你实际构造的请求体内容，否则服务器大概率解析失败：
- 发 JSON 数据时，用 application/json，且确保 body 是合法 JSON 字符串，并推荐显式加 ;charset=utf-8
- 用
fetch或XMLHttpRequest提交表单键值对（非文件），设为 application/x-www-form-urlencoded，并用URLSearchParams或手动拼接key=val&key2=val2 - 上传带文件的表单，必须用 multipart/form-data，且不能手动设置 boundary —— 浏览器或库会自动生成并写入 header 和 body
- 发送纯文本（如日志、配置片段），用 text/plain;charset=utf-8，避免服务器误判为 HTML 或乱码
容易出错的细节
很多问题不是因为没设 Content-Type，而是设得不匹配：
- 前端用
JSON.stringify(obj)构造 body，却设成 application/x-www-form-urlencoded → 服务器尝试 URL 解码 JSON 字符串，结果全乱 - 后端期望接收 application/json，但前端漏设 header，或设成了 text/plain → 后端跳过 JSON 解析逻辑，直接当原始字符串处理
- 发送含中文的表单数据，Content-Type 没带 charset=utf-8，而服务端默认用 ISO-8859-1 解码 → 出现乱码
- 手动拼接 multipart body 时，boundary 值与 header 中声明的不一致 → 服务器无法分割字段
验证是否生效的简单方法
在开发中可快速确认：
- 用浏览器开发者工具的 Network 面板，点开请求 → 查看 Headers 标签页下的 Request Headers → 确认 Content-Type 是否存在且值正确
- 用 curl 发送时加上
-v参数，观察实际发出的请求头 - 后端打印原始请求头和 body 字节流，比对解码前后的字符串是否符合预期
