Composer 2.1+ 才真正原生支持并行下载，低于此版本（如1.10.22）即使设置相关参数也完全无效；需先运行 composer --version 确认版本，若为1.x则执行 composer self-update 升级，并通过动态进度条（如Downloading (7/42)）和多包同时下载日志验证是否生效。
确认 Composer 版本是否支持原生并发下载
Composer 2.1+ 才真正启用并行下载逻辑，低于此版本（如 1.10.22）即使设置 http-max-concurrent-downloads 或 parallel-downloads 也完全无效。运行 composer --version 是必须的第一步。若输出为 1.x，直接执行 composer self-update 升级——别依赖“看起来在动”的假象。
验证是否生效：执行 composer install 时观察终端日志。出现类似 Downloading (7/42) 这种动态跳变的数字，且多个包名同时出现在下载行中，才是真并发；如果仍是一行卡住、再换一行，说明没跑起来，大概率是镜像源拦截或插件冲突。
设对 http-max-concurrent-downloads 值，而非瞎调高
parallel-downloads 在 Composer 2.2+ 已被弃用，当前唯一有效配置项是 http-max-concurrent-downloads（注意不是 max-concurrent-downloads，少一个单词就无效）。默认值通常是 6，但多数开发机设成 10 更稳：
composer config --global http-max-concurrent-downloads 10- 若报
file_put_contents(/tmp/): failed to open stream或Unable to create temporary file，立刻降到6或8——这是临时目录文件句柄争抢，不是网络问题 - 别设
20或50：镜像站会限流（如阿里云对单 IP 并发 >12 会返回429 Too Many Requests），本地磁盘 I/O 也可能成为瓶颈，反而触发大量重试 - 该设置只对
composer install有效；composer update因需实时解析依赖图，仍有明显串行段
必须配国内镜像源，否则并发就是空转
并行只是“同时发请求”，但如果目标是 packagist.org，DNS 解析慢、TLS 握手卡顿、CDN 路由绕行会让所有并发请求堵在连接阶段，实际效果可能比单线程还差。必须全局配置可信镜像：
- 阿里云（当前最稳）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清华（备选）：
composer config -g repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/ - 切完立即清缓存：
composer clear-cache，否则旧元数据还在走海外链路 - 验证是否生效：
composer config -g repo.packagist输出里应明确含"url": "https://mirrors.aliyun.com/composer/" - 已停用的
https://packagist.phpcomposer.com别再用，现在基本返回404
关掉干扰项，避免并发被拖垮
并发下载快了，但其他环节可能卡死整个流程。常见干扰点：
- 进度条本身会锁住输出缓冲：加
--no-progress和--no-interaction，尤其在 CI 中 - 某些企业内网镜像不支持
Range请求头，强行并发会触发大量416 Requested Range Not Satisfiable错误 - 杀毒软件（如 Windows Defender）或文件系统（如 macOS APFS）会对每个
file_put_contents调用同步扫描，解压一个.tar包生成数百个小文件时，I/O 直接从 120MB/s 掉到 8MB/s - 已失效插件如
hirak/prestissimo必须卸载：composer global remove hirak/prestissimo，它在 2.x 中会静默降级为单线程
真正影响速度的，往往不是“能不能并发”，而是“并发请求发出去后，有没有被服务端接住、有没有被本地磁盘/安全软件拦住”。调参前先看日志、测镜像连通性、关掉非必要钩子，比盲目改数字管用得多。
