composer不流式解析json，因json_decode()需完整字符串致内存暴涨；无公开api读composer.json，应直接文件读取或调用show命令；cache-files配置仅管包缓存，不影响元数据；clear-cache不释放运行时内存。
Composer 不使用流式读取解析元数据，它从不流式处理 packages.json 或 provider-*.json。
你看到的“卡在 provider-laravel~10.0.json”或“内存暴涨”，不是因为 JSON 解析慢，而是因为：
-
json_decode()要求整个响应体是完整字符串，必须一次性下载、一次性加载进内存 - 当
packages.json达到 20+ MB（全量索引），PHP 进程常驻该字符串 → 直接触发 OOM 或 GC 频繁回收 - Composer 源码里没有
fread()+ 状态机、也没有调用JsonStreamingParser类库
composer.json 里读不到元数据缓存路径？别硬查
PHP 运行时代码里想动态读取当前项目的 composer.json 内容，没有 Composer::getConfig() 这种 API。
你不能依赖 Composer CLI 的内部类去获取配置——它们不是公开接口，也不保证稳定。
正确做法只有两种：
- 直接
file_get_contents(<strong>DIR</strong> . '/composer.json')+json_decode()（注意 UTF-8 和 BOM） - 若需解析依赖关系，应走官方推荐方式：用
composer show --format=json命令输出后解析，或调用vendor/bin/composer的 JSON API（如show --tree输出结构化数据）
cache-files-maxsize 和 cache-files-ttl 控制的是文件缓存，不是元数据 GC
这两个配置项只影响 ~/.composer/cache/files/ 下的 zip/tar 包缓存：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
cache-files-maxsize：超限时触发清理最旧的包归档（默认 300MiB） -
cache-files-ttl：归档文件 6 个月不用就标记为过期（默认 15552000 秒）
它们完全不控制元数据缓存（repo/ 目录）的生命周期，也不干预 PHP 运行时的 GC 行为。
真正决定元数据是否重拉的，是 HTTP 层状态码（404 / 304）、ETag 缓存头，以及镜像同步延迟。
composer clear-cache --gc 并不释放运行时内存
这个命令只是遍历缓存目录，删掉过期或超限的文件，它：
- 不调用
gc_collect_cycles() - 不影响任何正在运行的 PHP 进程的内存占用
- 不清理 autoloader 符号表或 class_alias 映射残留
如果你观察到 CI 中执行完 clear-cache 后内存反而升高，大概率是因为：
- 下次
composer install必须重新下载所有 provider 文件 → 更多并发 HTTP 请求 → 更多 curl 句柄和临时 buffer - 或者项目里存在 autoload 路径污染（比如多个包都映射了
"App\": "src/"），导致类加载时意外创建循环引用，GC 扫描压力增大
真正需要关注的，从来不是“Composer 怎么流式读 JSON”，而是你有没有让 autoload 规则干净、镜像地址写对、以及是否在生产环境误装了 require-dev 包。
