核心矛盾是传统json_decode需全量加载内存，破局关键在于转向“边读、边解析、边消费”的流式路径，结合JSON Lines识别、拉式解析器（如pcrov/jsonreader）及即时消费（yield/写库），实现KB级内存稳定处理。
处理大数据量 JSON 数组时，核心矛盾是：传统 json_decode() 要求整个字符串合法且一次性载入内存，而真实场景中文件动辄几十MB甚至GB，直接解码必然触发内存溢出或超时。破局关键不是“调大 memory_limit”，而是放弃“全量加载→解码→处理”这一整套模式，转向“边读、边解析、边消费”的流式路径。
识别输入格式，决定解析策略
不是所有“JSON数组”都适合直接 json_decode()。先确认数据实际结构：
-
标准 JSON 数组（如
[{"id":1},{"id":2},...]）：语法合法，但若整体体积过大，json_decode()仍会失败。此时需配合流式读取 + 状态机拆分，或改用拉式解析器。 -
JSON Lines 格式（每行一个独立 JSON 对象，如
{"id":1}{"id":2}）：最易流式处理。用fopen() + fgets()逐行读取，每行单独json_decode()，内存占用恒定。 -
非法拼接 JSON（如
{"id":1}{"id":2}）：这不是有效 JSON，json_decode()必然返回null。必须借助pcrov/jsonreader或cerbero/json-parser这类拉式解析器，靠 token 流识别对象边界。
选用拉式解析器替代 json_decode
当数据是大型 JSON 数组或嵌套极深时，json_decode() 的树形构建机制就是内存瓶颈。拉式解析器（Pull Parser）不建树，只提供游标，按需读取当前节点类型、键名、值：
-
cerbero/json-parser：零依赖，API 简洁。实例化后可foreach遍历，每次循环仅加载一个键值对或数组元素到内存。 -
pcrov/jsonreader：类似 XMLReader，支持read()、getDepth()、getValue()等方法，适合需要精细控制解析流程的场景（例如跳过某些字段、提前终止）。 - 两者都不受
max_depth限制，也规避了json_decode()因深层嵌套导致的栈溢出问题。
流式读取 + 即时消费，避免中间数组堆积
即使用了拉式解析，若在循环里不断往 PHP 数组追加数据（如 $all[] = $item;），内存仍会线性增长。正确做法是“即用即弃”：
立即学习“PHP免费学习笔记（深入）”；
- 解析出一条记录后，立刻写入数据库、推入消息队列、导出 CSV 行，或 yield 返回 Generator。
- 用
yield封装解析逻辑，让调用方按需迭代，不缓存全部结果。例如：function parseLargeJson($file) { $parser = new JsonParser($file); foreach ($parser as $item) yield $item; } - 对只做过滤或转换的场景，完全不必保存原始结构——解析 → 判断 → 输出，三步闭环，内存峰值稳定在 KB 级别。
错误处理必须落在每次解析动作之后
流式处理中，某一行或某个节点解析失败不能中断全局，更不能依赖 json_last_error_msg() 获取上下文——它只反映最近一次调用状态，可能被前序操作污染：
- 每次
json_decode($line)后，立即检查返回值是否为null，并调用json_last_error()确认错误类型。 - 封装安全解码函数：
function safe_json_decode($json) { $data = json_decode($json, true); return $data !== null && json_last_error() === JSON_ERROR_NONE ? $data : false; } - 对无效行记录日志（含行号、原始内容片段），便于后续人工核查或重试，而非让整个任务崩溃。
