Composer无官方并发配置，github-protocols等参数仅影响源选择而非下载线程数；真正提速需依赖缓存插件或绕过Composer手动多线程下载，但后者风险高且破坏完整性校验。
composer config 的 github-protocols 和并发无关，别被误导
很多人搜到 github-protocols 或 preferred-install 就以为能调并发，其实这些只影响源选择和安装方式，完全不控制下载线程数。Composer 默认用 cURL 批量请求，但并发逻辑藏在底层，用户层没有公开配置项。
COMPOSER_PROCESS_TIMEOUT 和 COMPOSER_HOME 不解决下载慢
这两个环境变量常被误认为能加速：前者只延长单个进程超时时间，后者只是缓存路径。它们既不增加连接数，也不并行化 HTTP 请求。真正拖慢下载的，是 Composer 在处理大量包时串行解析 composer.lock、逐个发起元数据请求、再排队下载 ZIP 的流程。
唯一有效的隐藏参数：COMPOSER_DISABLE_TTY + 并行插件
Composer 原生不支持调整并发数，但可通过第三方插件绕过限制。目前最稳定的是 hirak/prestissimo（已归档）的继任者 clue/phar-composer 不推荐；实际可用的是 composer-plugin-parallel-downloader（需手动安装）：
- 运行
composer global require "kylekatarnls/update-helper:^2.0"仅辅助更新，不提速 - 真正起效的是
composer global require "szepeviktor/composer-cache-plugin:^1.0"，它启用本地缓存后，重复 install 时跳过下载，但首次仍慢 - 终极方案：改用
php -d extension=... -r "..."直接调 cURL 多线程下载 ZIP，再 patch 到vendor/—— 这已脱离 Composer 流程，风险高、难维护
所以，所谓“隐藏参数”本质是不存在的。Composer 的下载器是同步阻塞实现，硬改并发需重写 Composer\Downloader\ZipDownloader 类，且会破坏签名验证与完整性校验。
为什么官方不加并发配置？
Composer 设计目标是确定性与可重现性，不是速度。并行下载可能引发：
- GitHub API 频率限制触发（
403 rate limit exceeded） - 同时解压多个 ZIP 导致磁盘 I/O 瓶颈，反而更慢
- 内存暴涨（每个下载流缓存未解压内容），尤其在低配 CI 环境中直接 OOM
- PHP 的 stream context 不支持真正的 HTTP/2 多路复用，伪并发仍是 TCP 轮询
如果你在 CI 中卡在 download 阶段，优先检查是否用了 --no-interaction --no-progress 关掉进度条（它本身就会锁住输出缓冲），再确认是否启用了 composer cache。其它所有“调并发”的尝试，基本都在修幻觉。
