Postman发送JSON请求的核心是：必须设置Header中Content-Type为application/json，且Body需选raw并指定JSON格式；否则后端无法正确解析，易报HttpMessageNotReadableException等错误。
Postman 发送 JSON 数据，核心就两点：请求头必须声明 Content-Type: application/json，请求体必须用 raw 模式并选中 JSON 格式。漏掉任一环节，后端大概率收不到或解析失败。
为什么 Content-Type 一定要设成 application/json？
服务器靠这个头字段判断怎么解析请求体。如果只填了 JSON 内容但没设头，Postman 默认发的是 text/plain 或 application/x-www-form-urlencoded，后端框架（比如 Spring Boot 的 @RequestBody）会直接抛 HttpMessageNotReadableException，日志里常看到 “JSON parse error: unexpected character” 这类提示。
实际操作中注意：
- 手动添加时，
Key必须写成Content-Type（大小写敏感），Value写application/json，不要多空格、分号或 charset（除非后端明确要求） - 如果已在 Body 里选了
raw → JSON，Postman 通常会自动加这行 Header；但切换过环境或导入集合后可能丢失，建议每次发请求前快速扫一眼 Headers 页签 - 某些老旧网关或 Nginx 配置会过滤掉带下划线的 header 名，若遇到请求被拦截，可尝试把
Content-Type改成全小写content-type（非标准但部分服务能接受）
Body 选 raw + JSON 和选 form-data 有啥区别？
本质是数据编码方式不同：raw → JSON 把整个 JSON 字符串当二进制流原样发出去；form-data 是 multipart 编码，会把每个字段拆成独立 part，带 boundary 分隔——它根本不是 JSON，后端收不到完整 JSON 对象。
常见误操作场景：
- 点了
form-data，然后在 key 里填{"a":1}—— 这会被当成字符串字段名，不是 JSON 数据 - 选了
raw但下拉菜单没切到JSON，而是留在Text或Plain—— 此时 Postman 不校验语法，但服务器收到的 Content-Type 是错的 - JSON 里用了中文引号、尾随逗号、单引号，或键名没加双引号（如
{name: "a"}）—— 这些在 JS 里可能运行，但严格 JSON 标准不合法，后端解析直接报错
怎么快速验证 JSON 格式是否合法？
别靠肉眼数括号。Postman 在 raw → JSON 模式下，输入时会实时高亮语法错误（比如红波浪线），但这个检查不严格。更可靠的做法是：
- 粘贴 JSON 到在线校验工具（如 jsonlint.com）确认无误再复制回 Postman
- 用 VS Code 打开一个临时
.json文件，粘贴内容，编辑器会立刻标出错误位置 - 如果 JSON 来自代码生成，确保已调用
JSON.stringify()（前端）或ObjectMapper.writeValueAsString()（Java），而不是直接拼字符串 - 含嵌套对象或数组时，优先用缩进格式写，避免一行超长导致漏看逗号或括号
真正容易被忽略的点是：Postman 的 JSON 下拉选项只是个快捷方式，它不会帮你补全引号、修正转义或检测逻辑结构错误。哪怕语法合法，如果字段名拼错（比如 user_id 写成 userid）、值类型不对（后端要 number 却传了 string），照样 400 或 500。调试时先盯住响应体里的错误提示，比反复改 Body 更有效。
