更稳妥的做法，其实就两条：如果是 JSON Lines，就按行去解析，用 json.loads() 一行一行处理。同时，把 strip、utf-8 编码和异常捕获这些基础细节一并补齐。

如果面对的是单个嵌套 JSON，更合适的是用 ijson 做流式解析。比如通过 ijson.items(f, 'path')，并配合 rb 模式读取。

只有在结构本身比较混杂的情况下，才需要进一步上 ijson.parse() 这种事件驱动方式。

直接用 json.loads() 解超大 JSON 流，基本等于主动申请内存溢出。

真正可行的路径只有两条：按行解析（JSON Lines）或流式事件驱动（ijson）。选错就卡死。

遇到 "trailing garbage" 错误，说明你误用了 ijson 解析 JSON Lines

这个报错通常不在于代码本身写错了，症结出在文件格式和解析器没对上。

ijson 的设计目标，是解析一个完整的、带顶层结构的嵌套 JSON 文档，比如 [{...}, {...}] 这种。

但 JSON Lines 不是这个路子。它是一行一个独立的 JSON 对象，本身并没有统一的顶层容器。

结果就是，ijson 会把第一行当成一整份文档解析完。等读到第二行开头时，自然就会抛出 “trailing garbage” 这个错误。

• 正确做法：放弃 ijson.items()，改用内置 json.loads() 配合逐行读取
• 必须 line.strip() —— 换行符、BOM、空格都会让 json.loads() 直接抛 JSONDecodeError
• 必须显式指定 encoding="utf-8" —— 真实数据集常见 Latin-1 或带 BOM 的 UTF-8，不指定就崩
• 必须包 try/except json.JSONDecodeError —— 大文件总有半截行、转义错误、控制字符，不捕获就中断

处理标准大数组（[{},{},...]）时，ijson.items() 是最简稳解

别碰 ijson.parse() 做状态机——容易漏事件、难调试、维护成本高。

95% 的场景用 ijson.items(f, "item") 就够了。它内部已做缓冲优化，内存只驻留当前 item。

• 路径字符串要写对："data.item" 表示顶层 {"data": [...]} 里的数组元素；"item" 表示顶层就是数组 [...]
• 文件必须用 "rb" 模式打开 —— ijson 底层是字节流解析，传文本流会报 TypeError
• 不要在循环里反复调 ijson.items() —— 每次都重开文件、重置解析器，IO 开销翻倍
• 如果字段嵌套深（如 records.data.user.name），优先用 ijson.items(f, "records.data.user") 跳过无关层级，比 ijson.parse() + 手动匹配 prefix 更快更稳

想提速？换解析器，但别乱换

ujson 和 orjson 对单次 loads() 有 2–5 倍加速，但前提是：你已经在用逐行或 ijson.items() 控制住了内存。

它们不能解决“加载整个文件”的问题，只加速“解析这一行”或“解析这一个 item”。

• orjson 不支持 object_hook，如果你依赖 datetime 自动反序列化，得自己后处理
• ujson 对中文支持弱，某些 Unicode 字符会静默失败，生产环境慎用
• 替换方式很简单：把 import json 换成 import ujson as json，其余代码不动（ijson 不走这里）
• 真正瓶颈在 IO 时，加 mmap 比换解析器更有效 —— 特别是 SSD 上随机读大文件，mmap + ujson 组合可再降 20% 耗时

最后一个关键判断

最容易被忽略的一点：所有流式方案都依赖“结构可知”。

如果你拿到的文件既不是 JSON Lines，也不是标准数组，而是混着对象、数组、原始值的嵌套怪物，那 ijson.parse() + 状态机是唯一出路。

但这时你应该先确认，是不是上游导出逻辑本身就该修正。

《夸克》非常好用的免费AI浏览器

下载APP查看