json-machine通过流式解析实现恒定内存占用，解决传统json_decode因全量加载导致的内存溢出问题；它基于Generator逐项处理JSON，峰值内存与文件大小无关，实测100GB文件仅需3–5MB内存。
直接用 json_decode(file_get_contents($file)) 解析 25MB+ 的 JSON 文件，内存必然爆——这不是 PHP 版本问题，是数据规模和处理模型根本错配。
为什么 json_decode() 一读就崩？
它必须把整个 JSON 字符串加载进内存，再递归构建嵌套数组/对象。25MB 原始 JSON 解码后常占 100MB+ 内存；500MB 文件基本无解。更隐蔽的是：Web SAPI 下还叠加了 max_execution_time 和输出缓冲限制，脚本可能静默中断，连错误都不报。
- 别信
ini_set('memory_limit', '2G')—— 单请求吃掉 2GB 内存，高并发时 PHP-FPM 进程池直接雪崩 -
json_last_error()返回JSON_ERROR_NONE也不代表成功：若因超时被 kill，函数根本没执行完 - 用 CLI 运行只是绕过 Web 限制，不解决内存模型缺陷——仍会 OOM
用 json-machine 实现恒定内存解析
它基于生成器（Generator）做流式解析，只在内存中保留当前 JSON 项，峰值内存与文件大小无关。实测解析 100GB JSON，内存稳定在 3–5MB。
- 安装：
composer require halaxa/json-machine - 基础用法：
$items = \JsonMachine\Items::fromFile('data.json');，然后foreach ($items as $key => $value)迭代 - 只取子路径（如
/results/users）：Items::fromFile('data.json', ['pointer' => '/results/users']) - 若 JSON 是“多行 JSON”（每行一个独立对象），改用
Items::fromIterable(new \JsonMachine\LineReader('data.json'))
遇到嵌套深、含 BOM、非 UTF-8 怎么办？
流式解析器不自动处理编码和结构异常，这些得前置清理：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
立即学习“PHP免费学习笔记（深入）”；
- BOM 必须手动剔除：
$content = file_get_contents('data.json'); $content = ltrim($content, "\xEF\xBB\xBF");，再喂给Items::fromString() - 非 UTF-8 编码（如 GBK 中文）需转码：
$content = mb_convert_encoding($content, 'UTF-8', 'GBK'); - 嵌套超 512 层？传统
json_decode()会报JSON_ERROR_DEPTH，但json-machine不受此限——它根本不预建完整树 - 字段缺失或类型混乱？在
foreach循环里用空合并操作符：$name = $user->name ?? 'unknown';
比 json-machine 更轻量的替代方案
若项目不能引入第三方依赖，可用 pcrov/jsonreader（纯拉式解析器，零依赖）或手写简易状态机：
-
pcrov/jsonreader安装：composer require pcrov/jsonreader；核心是$reader->read()+$reader->value()，适合需精细控制节点遍历的场景 - 手写方案仅适用于“每行一个 JSON 对象”的日志类文件：用
fopen()+fgets()逐行读，每行调json_decode($line, null, 512, JSON_THROW_ON_ERROR)——注意显式传JSON_THROW_ON_ERROR避免 silent fail - 绝对不要用
substr()或正则硬切 JSON，结构稍复杂就崩溃
真正卡住人的从来不是库选不对，而是把“大文件”当成“一个整体”来对待。只要记住：任何需要 file_get_contents() 全量加载的方案，在 25MB+ 场景下都该被标记为危险操作。
