Python处理大型JSON文件时出现JSONDecodeError该如何修复？

确认了是合法的JSON数据之后，第二个常见的暗坑就是文件头带“脏东西”了。Windows环境下生成的UTF-8文件，经常自带一个叫BOM的字符\ufeff，某些老版本API的响应开头也喜欢来一段)]}'\n——这些前置的垃圾字符，会让json.loads()在解析第0个字符时就彻底懵掉。

• 读文件时直接用open(..., encoding='utf-8-sig')，比手动用.lstrip('\ufeff')要稳妥得多。
• 如果是网络响应，可以先做一步清洗：s = response.text.strip()，然后把前置垃圾手动删掉：s = s.lstrip(")]}'\n")。
• 有一个特别要注意的地方——很多新手会尝试用s.replace("'", '"')粗暴地把单引号替换成双引号。这是非常危险的操作，如果数据里有嵌套的单引号，比如“I'm great”，整个替换就会爆炸。这个方法只能在确认没有任何嵌套单引号时才考虑使用。

当基础检查都过关了，又碰到大文件解析问题？那通常是因为爆内存了。用json.load(f)去加载好几个GB的JSON文件，Python会一股脑儿把整个文件拉到内存里再解析，速度慢不说，还极容易触发MemoryError，甚至导致JSONDecodeError的定位出现错误偏移。

• 专业做法是改用流式解析。安装pip install ijson，用ijson.parse(f)一个事件一个事件地读，完全不加载全文。
• 如果内部流程要求必须全量加载，那可以先用命令行工具做一次快速验证。比如head -c 10000 big.json | python -m json.tool，先检查开头是否合法，排除截断问题。
• 另外需要警惕的是，解析出错时别过分依赖e.pos。在大文件里，制表符、\r\n、编码不一致都会导致列号偏移。更靠谱的定位方式是看e.lineno和e.colno，它们指向的行和列可信度更高。

最后一种情况，也是排查起来最烦人的——报错说“Expecting ','”或者“Expecting property name”。这类错误在大文件里往往最隐蔽。可能是传输中断导致数据被截断，也可能是后台日志系统在拼接多个json片段时漏掉了逗号或括号。光盯着报错那一行看，基本看不出啥。

• 一个立竿见影的招式是：用e.pos定位后，把前后50个字符打印出来：print(repr(data[max(0, e.pos-50):e.pos+50]))。这一招比只看行号更能暴露问题——比如你可能会发现文件在一个键值对中间突然断掉了。
• 记得检查数据里是否用了非标准格式。比如JSON标准不允许尾逗号（{"a": 1,}）和单引号（{'a': 1}）。如果你的数据源是内部系统或者自己是可控的，可以考虑用json5.loads()来解析（它对这些“不标准”的写法容忍度很高）。
• 如果数据源是你自己能控制的，最好的办法是加一道预校验。用python -m json.tool input.json > /dev/null在命令行先跑一遍，如果失败了，就没必要进入Python流程了。

说到底，真正麻烦的从来不是JSON语法错误本身。大文件里那些看不见的截断、BOM头、Windows和Linux换行符混用，以及服务端在出问题时悄悄返回的非JSON内容——它们不会明说“我错了”，只会让JSONDecodeError在最意想不到的位置冒出来。排查的时候，先别急着修改代码，先把拿到的“原材料”确认清楚，往往能省下大把时间。