JSON 格式化报错通常不是工具故障，而是原始文本不符合严格 JSON 语法。优先检查单引号、尾随逗号、未转义双引号和缺失括号，通常可以快速定位问题。
先确认输入的是严格 JSON
JSON 和 JavaScript 对象看起来相似，但规则更严格。属性名和字符串必须使用双引号，不能使用单引号，最后一个属性后面也不能保留逗号。
从日志、聊天窗口或代码文件复制内容时，还可能混入注释、不可见字符或代码块标记。排查前应先移除与数据无关的内容。
- 属性名必须使用双引号
- 字符串内部的双引号需要转义
- 数组或对象末项后不能有逗号
- 不能包含 // 或 /* */ 注释
四类最常见的语法错误
Unexpected token 往往表示解析器在当前位置遇到了不应该出现的字符；Unexpected end of JSON input 通常表示内容提前结束，常见原因是缺少右括号或右花括号。
如果错误位置靠近中文引号、换行或反斜杠，应检查是否使用了全角标点，或者 Windows 路径中的反斜杠是否正确转义。
- 单引号替代双引号
- 键值之间缺少冒号
- 相邻成员之间缺少逗号
- 括号、花括号或引号没有成对闭合
更快定位错误的步骤
先使用格式化工具执行校验，并记录错误附近的行列位置。然后从外向内确认最外层结构，再逐段缩小内容，直到找到导致解析失败的最小片段。
修复后重新格式化，并用实际程序再次读取。格式化成功只能说明语法有效，不代表字段类型和业务含义一定正确。
从错误提示反推问题位置
解析器给出的字符位置通常指向“发现异常”的地方，不一定就是最初写错的位置。例如漏掉前一个属性后的逗号，错误可能直到解析器读到下一个属性名才出现。因此要同时检查提示位置以及它前面的一个完整字段。
排查长 JSON 时，可以先复制错误位置附近的对象或数组到单独窗口，补上必要的外层括号后独立校验。如果片段能通过，再向外扩大范围；如果不能通过，就继续缩小到单个字段。这种二分排查比从第一行逐字寻找更高效。
- Unexpected token：重点检查当前字符及前一字段
- Unexpected end：重点检查末尾缺少的括号或引号
- Bad control character：检查字符串中的原始换行或制表符
- Property names must be quoted：检查未加双引号的键名
语法正确后还要检查字段类型
JSON 能被格式化，只说明文本符合语法。字符串形式的数字、字符串形式的 true、空字符串、null 和字段缺失，在业务上可能代表完全不同的含义。接口联调时应继续对照字段说明检查类型和是否必填。
大整数也需要特别注意。某些运行环境使用浮点数表示所有数字，超过安全整数范围后可能丢失精度。订单号、雪花 ID 和银行卡号等标识符即使只包含数字，也经常更适合作为字符串传输。
- 确认 number 与数字字符串是否混用
- 区分 null、空字符串和字段不存在
- 检查日期字段的格式与时区
- 大整数标识符优先使用字符串
提交接口前的 JSON 检查清单
先格式化并完成语法校验，再检查字段名称、大小写和层级。随后用一条最小有效数据完成请求，确认接口成功后再逐步加入可选字段，这样更容易判断是哪一部分触发了错误。
不要把包含访问令牌、密码、身份证号或真实用户数据的完整请求复制到公共渠道。需要协作排查时，应替换敏感值，同时尽量保留字段类型、长度和结构，以免脱敏后的样例无法复现问题。
- 保存原始输入，避免修复过程中丢失信息
- 使用最小数据验证接口基本路径
- 逐项添加可选字段定位业务校验错误
- 分享样例前完成敏感信息脱敏
立即处理
使用相关工具
常见问题
关于这个问题
JSON 可以使用单引号吗？
严格 JSON 不可以。属性名和字符串都必须使用双引号。
格式化成功是否代表接口数据正确？
不一定。它只代表语法可以解析，字段是否缺失、类型是否正确仍需按接口约定检查。