Composer不支持流式解析JSON元数据，所有packages.json和provider-*.json均依赖php原生json_decode()一次性加载，源码无流式读取逻辑；真正缓解内存压力需绕开Composer，改用cerbero/json-parser等离线流式库处理。
Composer 本身不支持流式解析 JSON 元数据，所有 packages.json 和 provider-*.json 都必须由 json_decode() 一次性加载进内存。你试图替换或绕过它，基本没用——源码里没有流式读取逻辑，也没有可插拔的解析器接口。
为什么不能在 Composer 中直接启用 JSON 流式解析
Composer 客户端在获取元数据时，HTTP 层使用标准 GET 请求，响应体是完整字符串，且要求 UTF-8 编码、语法合法；json_decode() 是硬编码调用，不接受流句柄、不支持增量 feed、也不暴露解析状态机。你传个 fopen(..., 'r') 给它，会直接报错 json_decode() expects parameter 1 to be string。
常见误操作包括：
- 试图 patch
Composer\Package\Loader\RootPackageLoader或Composer\Repository\ComposerRepository类，强行注入自定义解析器——但这些类只负责调用json_decode()，不处理底层 I/O - 用
stream_wrapper_register()拦截 HTTP 响应流——Composer 底层用的是Composer\Util\HttpDownloader，其返回值已是解压+拼接后的完整字符串，流早已关闭 - 以为升级到 Composer 2.5 就能自动流式解析——实际只是默认跳过全量
packages.json，改用分片provider-*.json，每个仍是独立完整 JSON 文件
真正有效的内存缓解路径：绕开 Composer 元数据流程
如果你的目标是“解析 Packagist 全量索引”，别在 Composer 运行时动脑筋，而是把数据导出后离线处理。这是唯一可控、可验证、不依赖 Composer 内部改动的方式。
推荐做法：
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 用
curl -s https://packagist.org/p2/all-packages.json（或镜像站对应 URL）下载原始 JSON，保存为本地文件 - 选用真正支持流式拉取的 PHP 库，例如
cerbero/json-parser或bcncommerce/json-stream，它们不调用json_decode()，而是基于词法扫描逐字符推进 - 对
packages.json这类扁平数组结构，用pcrov/jsonreader的JsonReader::read()+JsonReader::value()循环提取每个包名和版本，内存占用稳定在几 MB 级别 - 避免用
violet/streaming-json-encoder反向尝试“边解码边写入”——它只适用于编码场景，不提供解析能力
哪些库能真正替代 json_decode() 处理大 JSON
不是所有标榜“streaming”的库都适合元数据解析。关键看它是否绕开了 ext-json 扩展，是否支持随机跳过字段、是否允许中断重入。
实测可用选项：
-
cerbero/json-parser：纯 PHP 词法解析器，支持parseNext()按需消费 token，对packages.json这种千行级对象数组效率高，但对深度嵌套的provider-laravel~10.0.json需手动管理栈深度 -
bcncommerce/json-stream：基于salsify/jsonstreamingparser改写，提供JsonStream::parse()回调接口，适合监听start_object/key/value事件，但不支持回溯 -
pcrov/jsonreader：最接近 XMLReader 的体验，支持next()、readInnerXml()、moveToAttribute()，对含注释或混合结构的 JSON 更鲁棒
注意：json_decode($json, null, 512, JSON_INVALID_UTF8_IGNORE) 这类参数调整毫无意义——内存爆炸根源是字符串本身驻留，不是解析选项。
真正的分水岭不在“用不用流式库”，而在于你是否接受把元数据解析从 Composer 生命周期中剥离出来。一旦你开始写脚本下载 + 离线解析，问题就从“怎么 hack Composer”变成“怎么选对 parser”，后者有明确答案；前者只会不断撞墙。
