“Unexpected token in JSON” 大概是被搜索最多的解析错误。报错之所以没用，是因为解析器报告的是它放弃的位置，而不是你想表达的意思。几乎所有报错都出自下面 7 个原因，每个都有对应的修法。
1. 尾逗号
{"a": 1,} —— JSON 的数组和对象不能以逗号结尾。JavaScript 对象允许（ES2017 起），这正是从 JS 源码复制到 API 载荷或配置文件时高发的原因。修法：删掉闭合括号前的逗号。
2. 单引号
{'a': 1} —— JSON 的字符串和键必须用双引号，没有例外。单引号写法是合法的 JavaScript、但不合法的 JSON。修法：替换引号；如果数据本来来自 JS 字面量，过一遍 JSON.stringify（它还能顺带处理转义）。
3. 字符串里有裸换行
{"text": "第一行
第二行"}字符串字面量里不允许裸换行。修法：转义成 \n；如果内容本来就是多行数据，先过一遍 JSON 转义再嵌入。
4. 注释
{ /* 配置 */ "a": 1 } —— JSON 没有注释语法，这是刻意为之（Crockford 当年删掉注释就是为了让它成为纯数据格式）。需要注释的配置请用 YAML、TOML 或 JSON5；工具若强制严格 JSON，把注释挪到 _comment 键或旁边文档里。
5. 智能引号
{"a": "smart"} 里内侧的引号其实是 U+201C/U+201D——从 Word、部分聊天软件复制时被”自动美化”。大多数字体里它和直引号长得一样，解析器看到的是垃圾。修法：在编辑器里重新敲引号，或粘进 JSON 格式化器让它指出出错的字节。
6. 文件开头的 BOM
{ 前面的 UTF-8 BOM（EF BB BF）会报”Unexpected token “并指向第 0 字节。Windows 编辑器保存配置文件时常见。修法：另存为”UTF-8 无 BOM”。
7. 一行一个 JSON 值的约定被破坏
JSON Lines / NDJSON 数据里，跨多行的 pretty-printed 对象就是多个解析错误——每行必须是独立完整的值。修法：把每个对象压成单行；JSON Lines 校验器能指出出错行，还能把普通 JSON 数组转成合法 JSONL。
找出任何一种错误的调试习惯
看报错位置后，往前一个 token看，别盯着报错位置本身：解析器总是在实际错误之后一个字符才失败。一个能显示行列号的校验器——比如完全在浏览器本地运行的 JSON 格式化器（含敏感数据的载荷不出本机）——能把这七种错误从十分钟排查变成十秒修复。