JSON 修复实战：从报错位置到可靠数据的完整排查流程

接口日志、复制自 JavaScript 的对象和人工编辑过的配置经常只是接近 JSON，直接交给解析器就会失败。修复工作的目标不是让错误提示消失，而是在不误改业务含义的前提下，得到能够验证和复现的结果。

一、先保存原始输入

不要覆盖唯一副本。先把原始文本保存为单独文件，记录来源、时间和请求编号。日志可能包含令牌、邮箱或内部地址；使用工具前应移除不需要的敏感字段。这样当修复结果改变字段含义时，可以回到原始证据重新判断。

二、从第一个错误开始

常见损坏包括单引号、属性间缺少逗号、把布尔值写成 True，以及在数组最后保留逗号。解析器通常只报告第一个无法继续的位置，因此不要一次凭感觉修改全部字符。应按顺序处理：键与字符串改用双引号；补齐相邻属性间的逗号；把布尔值和 null 改为标准小写形式；删除对象或数组最后一个成员后的逗号。

可以把候选内容放入 JSON 修复工具，查看每一步变化，再把输出送入 JSON 验证器 独立复核。修复第一处错误后出现新的错误很正常，因为解析器此前无法可靠理解后续结构。

三、注释不能用简单替换删除

双斜线和块注释属于 JavaScript 语法，不是标准 JSON。删除注释前要确认符号不在字符串内部，例如网址中的双斜线必须保留。可靠修复器应先识别字符串边界，再处理真正的注释，而不是对全文执行正则替换。如果注释携带业务说明，应迁移到文档或明确字段，不能静默丢弃。

四、截断数据不能安全猜测

网络中断可能只留下半个数组或尚未完成的字段。工具可以补齐括号，却不知道缺失的编号、对象或数组成员。此类结果即使语法有效，也不代表数据完整。正确动作是重新获取来源数据，或把记录标记为不完整，不能把猜测值写回数据库。

同样需要人工判断的情况包括重复键、数字前导零、超大整数、日期字符串、NaN 和 Infinity。重复键在不同解析器中可能保留第一个或最后一个值，应回到数据生产者修复。超过 JavaScript 安全整数范围的标识符通常应按字符串传递。

五、完成四层验收

1. 语法验证

使用浏览器解析器和项目实际使用的后端解析器确认结果都能读取。两个环境可能对重复键或大整数有不同处理。

2. 结构验证

检查根节点类型、必填字段和字段类型。语法正确并不代表接口契约正确，字符串形式的年龄仍可能违反数字类型要求。

3. 语义核对

把修复前后结果放入 JSON Diff，确认变化只发生在预期位置，重点复核金额、权限、状态和标识符。

4. 回归测试

把损坏样例加入测试集，覆盖空对象、嵌套数组、转义字符、Unicode、重复键和截断输入。每次修改修复算法后重新运行，防止旧问题复发。

六、什么时候不应自动修复

临时粘贴的调试内容可以提供建议修复，但支付、权限、医疗、审计日志或数据库迁移数据不应在无人确认时自动改写。高风险流程应只报告错误位置和候选修改，由操作者确认后再生成结果。

总结

可靠的 JSON 修复遵循保留原文、修第一处错误、记录变化、再次验证、核对业务含义的顺序。自动工具适合明确的标点、引号和标准字面量问题，却不能替代对缺失数据和业务规则的判断。只有结合验证器、Diff 和项目测试，才能把能解析提升为可以信任。