「这看起来不就是 JSON 吗，为什么报解析错误」—— 因为 JSON 的语法比 JS 对象字面量严格得多。报错信息里的行号和列号已经指向了现场，剩下的是认得出病因。

第一步永远是拿到位置

把内容粘进 JSON 格式化，解析失败时页面给出行号、列号，以及该位置前后 40 个字符，并主动扫描结尾多余逗号、单引号字符串、注释、NaN 与 undefined 这四类常见错误。比只报一个 Unexpected token 的定位快很多。

六类原因与改法

一、单引号。 {'name':'张三'} 不合法，JSON 的字符串必须用双引号。从 JS 代码或 Python 打印结果里复制的，多半都是这种。全部改成双引号即可。

二、结尾多余逗号。 {"a":1,"b":2,} 或数组最后一项后面的逗号，JS 允许、JSON 禁止。删掉那个逗号。

三、注释。 双斜杠开头的行注释、斜杠星包围的块注释，都不是 JSON 的一部分。带注释的配置属于 JSONC，这一页不支持 JSON5 与 JSONC，只检查语法是否合法，需要先把注释删掉。

四、字符串里有真换行。 字符串中间不能出现未转义的换行，必须写成反斜杠加 n 的转义序列。从聊天窗口、Word 里复制的多行内容最常见，粘贴时看着正常，实际每一行都是一个非法字符。

五、多段拼接。 接口日志里连续输出两个对象 {...}{...}，整体就不是合法 JSON。每一段单独解析，或改成数组包起来。

六、内容被截断。 复制时没选全、日志被切断，表现是报「Expecting value」但位置在末尾。用统计项核对：字符串、数字、布尔、null 的数量与键名总数，跟预期差太多就是掉了一段。

三个隐蔽的坑

中文引号。 「" 与 " 被手打进键名或值里，视觉上和内容混在一起。报错列号会指向那个看不太出来的位置。

裸写的数字与 null。 NaN、undefined、Infinity 是 JS 的值，不是 JSON，必须改成 null 或数字。这一页会专门扫描它们。

BOM 头。 文件开头带 EF BB BF 时，某些解析器会把第一个键名前当成多余字符。站内的 TXT处理 能识别并去掉 BOM。

修完之后建议再做两件事

一是压缩成单行再存，避免二次粘贴时又混进换行。二是用「递归排序键名」做版本比对 —— 同样的数据两次导出，键顺序不同会让 diff 全是噪音，排序后才能真正比出差异。

注意这条边界：排序只作用于对象的键，数组内元素顺序保持不变。需要按数组内容排序的场景，得自己按业务字段排。