Composer 2.2+ 默认未启用并行下载，需手动配置http-max-concurrent-downloads（如设为8）并确保镜像源、cURL支持、干净缓存三者协同，否则自动退化为串行；验证方式是运行composer install -vvv，观察日志中是否出现多行Downloading几乎同时打印。
Composer 2.2+ 默认已启用并行下载，但不等于“开箱即用就快”——它需要镜像源、cURL 支持、干净缓存和合理并发数四者咬合，缺一就会退回串行表现。
怎么确认并行是否真在工作
别信速度感觉，看 -v 日志里有没有交错的 Downloading 行：
- 如果日志严格按顺序打印每个包的
Downloading https://...，说明并行被绕过或失效 - 如果两行及以上
Downloading几乎同时出现（哪怕只差几百毫秒），说明并发请求已发出 - 加
-vvv可看到更底层的 cURL multi 初始化日志，如Using curl_multi for parallel downloads
常见假象：日志里有并发痕迹，但实际仍慢——大概率是镜像源限流或 DNS 卡在握手阶段，不是 Composer 本身问题。
composer config -g http-max-concurrent-downloads 是什么
这是 Composer 2.2+ 控制并发连接数的核心配置项，不是插件、不需安装，直接生效：
-
composer config -g http-max-concurrent-downloads 8全局设为 8 路并发（推荐值） - 值设太高（如 16）易触发阿里云/腾讯云镜像的
429 Too Many Requests或 GitHub API 的403 rate limit exceeded - 值设太低（如 2）等于没开，并发收益几乎为零
- 该配置只影响
install阶段的 ZIP 下载，update的元数据请求仍是串行
为什么加了 --parallel 还卡在 Downloading
--parallel 是 Composer 2.2+ 的命令行快捷写法，等价于 --parallel=4，但它会静默失效于以下场景：
- 删了
composer.lock或运行composer update→ 并行自动禁用，因版本未锁定 - PHP 未启用
curl扩展（php -m | grep curl确认），会降级为串行且无报错 - 用了老旧私有源（如旧版 Satis），返回 302 跳转而非直接 ZIP URL，导致并发流程跳过
- 本地 DNS 缓存污染或出口带宽小（如 10M 宽带跑 10 并发），连接建立阶段就排队阻塞
vendor 写入慢，并行反而更卡
并行下载快了，但解压后往 vendor/ 写文件可能成为新瓶颈，尤其在这些环境：
- macOS APFS 或 Windows NTFS + 实时杀毒软件（如 Windows Defender）会拦截每个
file_put_contents调用 - NFS 挂载卷上大量小文件解压，并行加剧磁盘寻道竞争
- CI 环境中
fsync强制刷盘，一个 2MB ZIP 解压成 300 个文件，就触发 300 次同步写
临时缓解：CI 中可关掉实时扫描，或改用 composer install --no-autoloader --no-scripts 跳过后续串行步骤，把 autoload 和脚本留到构建末尾单独执行。
最常被忽略的一点：并行下载只是整个 install 流程的第一环。它不加速 autoload 生成、不绕过 post-install-cmd、也不减少磁盘 I/O 延迟——把所有优化都堆在 --parallel 上，就像给自行车装涡轮增压，轮子卡在泥里照样动不了。
