Postman中Content-Type必须显式设为application/json，否则即使Body选JSON也会因头缺失或错设为text/plain导致415错误；Headers中已存在该键时不会自动覆盖，需手动检查并确保值准确无空格或非法字符。
Content-Type 必须显式设为 application/json
Postman 不会自动根据 Body 内容推断请求头，哪怕你选了 JSON 格式、输入了合法 JSON，Content-Type 仍可能为空或错设为 text/plain。服务器收到无 Content-Type: application/json 的 POST 请求时，通常直接返回 415 Unsupported Media Type 或静默解析失败。
正确做法是：在 Headers 标签页手动添加一行：
-
Key填Content-Type（注意大小写，部分老版本后端对大小写敏感） -
Value填application/json（不加空格、不加charset=utf-8，除非接口文档明确要求） - 如果已存在该 Key，检查值是否被覆盖成其他类型（比如误填成
application/json; charset=UTF-8，分号后多空格也可能触发某些网关拦截）
Body 选 raw + 下拉选 JSON 不等于自动设好请求头
Postman 在 Body → raw → JSON 模式下，**仅当 Headers 中没有 Content-Type 时**，才会自动补上 application/json；一旦你之前设过该 Key（哪怕值为空或错误），它就不会覆盖。这个行为容易被忽略，导致“明明选了 JSON 却报 400”。
实操建议：
- 每次新建请求后，先清空
Headers表格再重新添加Content-Type - 不要依赖下拉菜单的“自动填充”，始终以
Headers标签页中实际显示的值为准 - 若需带 BOM 或 UTF-8 编码声明，应写成
application/json; charset=utf-8（注意分号后无空格），但多数现代 API 不需要
遇到 415 Unsupported Media Type 先查这三处
这个错误几乎只和媒体类型声明有关，不是后端逻辑问题。排查顺序很固定：
- 打开
Headers标签页，确认Content-Type存在且值为application/json（不是text/json、application/javascript等非常规值） - 点开
Body标签页，确认选的是raw而非form-data或x-www-form-urlencoded；后者即使内容是 JSON 字符串，也会被当成表单提交 - 用 Postman 控制台（View → Show Postman Console）查看真实发出的请求，核对
Content-Type是否出现在原始请求头中——有时环境变量或预请求脚本会意外覆盖它
带认证时 Authorization 和 Content-Type 是并列关系
很多人以为设了 Content-Type 就够了，结果因缺鉴权头被 401 拦截，误判为 JSON 格式问题。其实这两个 Header 完全独立：
-
Content-Type解决“数据怎么解析” -
Authorization解决“你是谁” - 两者必须同时存在，且不能合并或嵌套（例如不能把 token 塞进
Content-Type值里） - 常见写法：
Authorization: Bearer {{token}}，其中{{token}}是环境变量，避免硬编码
最易被忽略的是：当切换环境（如 dev → prod）时，Authorization 值可能没同步更新，而 Content-Type 看似正常，导致请求发出去却卡在认证层——此时响应体常为空，状态码是 401，但新手常回头去调 JSON 格式。
