Postman中JSON字段值含双引号必须转义为"，且Content-Type必须设为application/json，否则服务端解析失败；全角引号、BOM、控制字符等隐形非法字符同样导致400错误。
Postman 里 JSON 字段值中要包含双引号（"），必须用反斜杠转义为 "，否则请求体直接非法，服务端解析失败——这不是 Postman 的限制，而是 JSON 规范强制要求。
Postman 中 JSON 字段含双引号的写法
JSON 标准只允许用 ASCII 双引号 " 包裹字符串，且字符串内部若出现 "，必须写成 "。Postman 的 Body → raw → JSON 模式会把内容原样发出去，不做额外处理，所以你写的就得合法。
常见错误写法：
-
{ "msg": "He said "Hello"" }—— 解析失败，第二个"被当成字符串结束符 -
{ "msg": "He said “Hello”" }—— 全角引号（U+201C/U+201D）不是合法 JSON 字符
正确写法：
{ "msg": "He said "Hello"" }-
{ "path": "C:\Users\admin" }—— 反斜杠也要双写，因为 JSON 里是转义起始符 - 如果字段值本身来自用户输入（比如评论、标题），建议在前端或服务端做预处理：用
JSON.stringify()生成字符串值，再塞进外层 JSON，避免手写转义出错
Postman 发送时 Content-Type 必须设为 application/json
即使 JSON 写对了，如果请求头没声明格式，服务端大概率按 application/x-www-form-urlencoded 或纯文本解析，结果就是 400 或字段为空。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 在 Postman 的 Headers 标签页手动加一条：
Content-Type: application/json - 不要依赖 Postman 自动识别——它只在你选了 Body → raw → JSON 时才可能自动加，但某些版本或旧配置下会漏掉
- 后端如 Go/Java/Spring Boot 都严格检查该 header；Node.js 的
express.json()中间件也依赖它触发解析
中文引号、空格、BOM 这些隐形坑
Postman 编辑器本身不校验 JSON 合法性，很多报错其实来自肉眼难见的字符：
- 从 Word、微信、网页复制过来的
“和”（U+201C/U+201D）会被当非法字符，Go 的json.Unmarshal直接报invalid character '‘' looking for beginning of object key string - 文件开头有 UTF-8 BOM（
EF BB BF）会导致部分老服务端拒绝解析，Postman 不显示 BOM，但用curl -v或抓包能看到 - 末尾多一个逗号、少一个大括号、键名没用双引号（如
{ name: "x" }）——这些都会让 JSON 失效，Postman 不提示，但服务端返回400 Bad Request或空响应体
调试建议：把 Postman 里的 JSON 粘贴到 jsonlint.com 验证；或者用 echo '{...}' | python3 -m json.tool 快速校验。
复杂字符串（含换行、制表符）怎么安全传
JSON 不允许未转义的换行符（
）、制表符（ ）等控制字符直接出现在字符串中，否则解析中断。
- 手动写：把换行写成
"desc": "line1 line2 indent" - 更稳妥的方式：在代码里用
JSON.stringify()（JS）、json.dumps()（Python）、MarshalJSON()（Go）生成完整 JSON 字符串，再复制进 Postman —— 这些函数会自动处理所有转义 - 注意：Postman 的 raw 输入框里按 Enter 键产生的真实换行，在 JSON 中是非法的，必须替换成
真正容易被忽略的，是那些“看起来没问题”的字符串——比如从 Excel 导出的字段带不可见空格、从数据库查出来的字段含零宽字符、甚至同事发来的 JSON 片段里混用了全半角标点。这类问题不会报明显语法错，但会让服务端解析出空值或截断，得靠 io.ReadAll(req.Body) 打印原始字节才能定位。
