Composer不使用自定义JSON解析器，所有元数据均依赖PHP原生json_decode()一次性解析；所谓“同步慢”实为镜像未完成同步所致，真正瓶颈在于大文件下载与内存占用，而非解析性能。
Composer 本身不使用自定义 JSON 解析器
Composer 客户端从不替换或绕开 json_decode()，所有元数据（packages.json、provider-*.json）都依赖 PHP 原生 ext-json 一次性解析。它不内置流式解析器，也不调用 JsonStreamingParser 或任何拉式/推式第三方实现。
你看到的“同步慢”“卡在 provider-laravel~10.0.json”，不是 JSON 解析耗时，而是该文件尚未被镜像站生成或拉取完成——curl -I 对比 Packagist 和镜像 URL 就能验证这点。
- Composer 源码里没有
fread()+ 状态机的 JSON 流式读取逻辑 - 所有 JSON 响应体必须是完整、合法、UTF-8 编码的字符串，否则
json_decode()直接返回null - HTTP 层用的是标准
GET，无Transfer-Encoding: chunked，也无 streaming hint
大文件场景下真正瓶颈不在解析，而在下载与内存
当 packages.json 达到 20+ MB（Packagist 全量索引），问题根源是：一次下载 + 一次 json_decode() → 整个字符串常驻内存 → OOM 风险。这不是 json_decode() 太慢，而是策略错了。
Composer 2.2+ 已默认跳过全量 packages.json，改用分片 provider-*.json（单个通常
- 不要指望换 Composer 版本“自动优化大 JSON”——它不负责替你做流式提取
- 若需处理 GB 级 JSON Lines 日志或导出数据，应脱离 Composer 生态，直接用
cerbero/json-parser这类拉式库按需读字段 -
cerbero/json-parser不调用json_decode()，也不依赖ext-json；它是纯 PHP 实现的词法扫描器，适合规避内存爆炸，但对小 JSON 反而更慢
想绕过分片延迟？改客户端行为，而非协议
Packagist 的 JSON 格式、镜像同步逻辑、分片命名规则，你无法修改。唯一可控的是 Composer 客户端如何应对 404 或空响应。
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
当 provider-laravel~10.0.json 暂不可用时，Composer 会 fallback 到 packages.json（更慢）甚至报 Could not find package。这不是 bug，是设计使然。
-
--ignore-platform-reqs不解决元数据缺失，它只跳过 PHP 扩展检查 - 临时切源最有效：
composer config -g repo.packagist composer https://mirrors.ustc.edu.cn - CI 中可加重试逻辑：检测
provider-*.json返回 404 后 sleep 10s 再试，而非立刻 fallback
运行时读取 composer.json 的正确姿势
PHP 代码里想获取 composer.json 内容，没有 Composer::getConfig() 这种 API。你必须自己定位、读取、解析。
硬编码 ./composer.json 是常见错误——脚本执行路径可能任意，getcwd() 未必是项目根目录。
- 向上遍历目录直到找到
composer.json，或到达磁盘根（/或C:\） - 留意
COMPOSER环境变量：若设为COMPOSER=composer-dev.json，就读这个文件，不是默认名 -
vendor/composer/installed.json和composer.lock不含原始配置字段（如autoload、config、scripts），只存求解结果
