JSON 错误信息经常指向解析器放弃的位置，而不是错误真正开始的位置。最快的修复方式，是先给失败分类，再修改文档。
首先确认输入完整且确实是 JSON，然后把严格语法问题与 JSONC 或 JSON5、传输失败、编码问题和 Schema 不匹配分开。这样可以避免随机改动掩盖原始原因。
逗号或括号附近出现 Unexpected token
在 } 或 ] 前的尾逗号可以出现在部分 JavaScript 场景中，但严格 JSON 不允许。删除它后，再检查前一个属性是否缺少值。意外的结束括号也可能说明更早的对象或数组关闭顺序错误。
单引号和未加引号的 key
JavaScript 对象字面量和 JSON5 可以使用 JSON.parse 会拒绝的语法。应把单引号字符串转换为正确转义的双引号字符串，并为每个对象 key 加双引号。当值中可能出现撇号时，不要直接全局替换。
注释和控制字符
严格 JSON 不允许单行或块注释。字符串中的真实换行、Tab 和部分控制字符必须转义。如果注释有意义，应把源文件保留为 JSONC，并为 API 生成严格 JSON 产物。
被当作 JSON 的 HTML 或空响应
常见的“Unexpected token <”通常说明服务端返回了 HTML 登录页或错误页。Unexpected end 可能表示响应为空或被截断。修改 payload 前先检查状态码、Content-Type、重定向、正文长度和网络失败。
语法有效但数据错误
如果解析成功但应用拒绝数据，应检查 Schema。字符串和数字不能随意互换，null 与属性缺失不同，数组元素可能要求统一类型，日期也只是普通字符串，除非应用进一步验证格式。
可重复的修复顺序
保留原始响应，检查传输元数据，识别 JSON 方言，利用错误位置格式化，只修复已知语法问题，验证结果，并把修复输出与源文件对比。生产环境应修复数据生产方，而不是永久在下游修补错误 API 数据。
总结
大多数 JSON 失败可以归为几类：方言不匹配、分隔符或引号错误、字符串转义无效、服务端返回非 JSON、内容截断或 Schema 不匹配。先判断类别，修复最早的原因，并保留原始输入用于对比。