JSON报错应优先用JSONLint或VS Code校验，而非肉眼排查；变量引用必须加双引号如"{{user_id}}"；禁用中文引号、BOM和注释；Content-Type与Body模式须严格匹配为application/json。
Postman里JSON报错但看不出哪错了
直接看 raw body 文本几乎不可能定位问题——人眼对引号、逗号、括号的微小差异极不敏感。最有效的做法是把当前请求体复制出来，粘贴到 JSONLint.com 或 VS Code（装 JSON 插件后会实时标红）里校验。常见现象包括：Unexpected token 'b'、Unexpected end of JSON input、Invalid character，这些基本都指向语法层面的硬伤，不是逻辑或字段名问题。
变量引用必须加双引号才能嵌入JSON
这是 Postman 用户踩得最多也最隐蔽的坑：在 raw JSON body 里写 {{user_id}} 是错的，必须写成 "{{user_id}}"。否则 Postman 会把变量值原样拼进去，导致 key 缺少引号、字符串没包裹、甚至整个 JSON 结构被破坏。比如：
- 错误写法：
{"id": {{user_id}}, "name": "test"}→ 若user_id值为123，实际发送的是{"id": 123, "name": "test"}（看起来合法，但若值是abc就变成{"id": abc, ...}，直接报错） - 正确写法：
{"id": "{{user_id}}", "name": "test"}→ 无论变量值是数字、字符串还是 null，都作为字符串安全嵌入
注意：只有在 raw 模式且 Content-Type 为 application/json 时才适用该规则；form-data 或 x-www-form-urlencoded 下不生效。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
中文引号、BOM、注释都会让JSON解析失败
Postman 编辑器默认用英文标点，但如果你从 Word、微信、网页复制 JSON 过来，极易混入全角引号（“”）、BOM 头（EF BB BF）或双斜杠注释（//）。Go、Java、Spring 等后端框架的 JSON 解析器严格遵循 RFC 8259，遇到这些字符会直接抛 Invalid character。解决方法：
- 在 Postman 的 raw 编辑框中按
Ctrl+Shift+P（Windows）或Cmd+Shift+P（macOS），输入 “Change Encoding” 并选UTF-8清除 BOM - 手动替换所有
“和”为英文双引号" - 删掉所有
//、/* */形式的注释（Postman 不支持 JSON 注释，也不自动剥离）
Content-Type 和 Body 模式必须匹配
即使 JSON 写得完全正确，如果 Postman 没配对 Content-Type 和 Body 类型，后端也会报错，典型如 415 Unsupported Media Type 或 Required request body is missing。必须同时满足：
- Body 标签页选
raw，右侧下拉菜单选JSON（这会自动加Content-Type: application/json） - 如果手动在 Headers 里加了
Content-Type，确保值是application/json，不能是text/plain或漏掉application/前缀 - 避免在 Body 选
form-data却往里面填 JSON 字符串——这时 Postman 会把它当文件字段发，后端根本收不到原始 JSON
真正容易被忽略的是：Postman 的 JSON 下拉选项只是个提示，它不校验内容；你切过去之后仍可能粘贴了一段非法 JSON，而界面毫无警告。
