JSON 格式错误怎么找：看懂报错位置
格式化 JSON 本身很简单。困难的是文件无法解析时，一条指向某个位置的报错，却常常不是真正出错的地方；真正的错误往往在它前面几个字符。
报错位置只是线索，不是结论
解析器报告的是它再也无法继续的位置，而这常常紧跟在真正的错误后面。新键前面少一个逗号，却会报在新键上；右括号前多一个逗号，却会报在右括号上。把报错那一行和它上一行放在一起看。
最常见的原因是尾部多余逗号、用单引号代替双引号、从文档里一起粘进来的注释，以及没有加引号的键名。这些都属于语法问题，而不是数据内容，修好它们不需要改动任何值。
语法错误和数据错误要用不同办法修
文件能解析之后，剩下的问题都属于含义层面：本该是数字却存成字符串、日期格式前后不一、一百条记录里有一条缺少字段。这些问题不会报错，所以「格式化成功」绝不等于「内容正确」。
一个有效的检查，是把格式化结果和使用方期望的结构比对。缺少的必填字段即便括号都对齐，到了下游依然会失败。
压缩格式要按用途保留
带缩进的 JSON 用于阅读和审查，紧凑的 JSON 用于传输或存储。不要提交一份只和原文件差在空格和缩进上的改动，也不要给接口发送这种版本。每种用途选定一种形式，验证通过之前保留原文件。
如果文件大到难以流畅阅读，缩进格式化反而会让处理更慢。先统计行数和字节数，只有在一清二楚的结构下才拆分出合法的片段来处理。
稳妥的处理顺序
- 把原文粘贴到副本里，不要直接修改唯一的版本
- 按项目约定的缩进风格格式化
- 如果失败，检查报错所在行以及它上一行
- 检查是否混入 JSON 不允许的注释和单引号
- 解析通过后，再核对键名和值类型是否符合预期结构
- 只有确认目标需要紧凑格式时，才重新压缩