Composer install 默认不支持多线程下载，所谓“多线程优化”实际依赖底层 HTTP 客户端行为和并行包解压策略，不是靠开多个 curl 进程实现；其提速关键在于复用本地缓存、并发 HTTPS 请求、调用系统 unzip 命令及跳过 dev 依赖，而非真正多线程。
Composer install 默认不支持多线程下载，所谓“多线程优化”实际依赖的是底层 HTTP 客户端行为和并行包解压策略，不是靠开多个 curl 进程实现的。
为什么 composer install 看起来变快了？
Composer 2.0+ 默认启用并行安装（parallel 模式），它把包下载、校验、解压、安装拆成可重叠的阶段，并复用已缓存的 ZIP 包。真正提速的关键不是“多线程下载”，而是：
– 复用本地 ~/.composer/cache/files/ 中已下载的归档
– 同时发起多个 HTTPS 请求（受限于 curl 的连接池和 PHP 的 stream_context 配置）
– 解压操作交给 unzip 或 7z 命令（若系统存在），而非纯 PHP 实现
– 跳过已满足 require-dev 条件且未启用 --dev 的包
如何确认是否启用了并行安装？
运行 composer install -v，观察输出中是否有类似：Downloading https://repo.packagist.org/p2/symfony/console.jsonDownloading https://repo.packagist.org/p2/laravel/framework.json
这类并发请求日志。如果看到多条 Downloading 行交错出现，说明并行已生效。
注意：
– 并行开关由 COMPOSER_PARALLEL_INSTALLS 环境变量控制，默认为 1
– 若设为 0，会退化为串行模式
– 在 CI 环境中某些镜像源（如阿里云镜像）可能因限流主动降级为单连接
composer install 的真实瓶颈在哪？
多数项目卡顿并非出在下载阶段，而是：
– vendor/autoload.php 生成耗时（尤其含大量 classmap 的包）
– post-install-cmd 脚本阻塞（如 php artisan optimize 或 npm install）
– 文件系统写入慢（如 NFS、Docker volume、Windows WSL2 overlayfs）
– Composer 自身校验逻辑（SHA256 + GPG 签名校验，尤其启用 verify-peer=true 时）
可临时跳过校验测试速度：composer install --no-plugins --no-scripts --no-suggest
能手动加速的几个有效动作
– 设置国内镜像：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
– 清理无效缓存：composer clear-cache（旧缓存可能含损坏 ZIP）
– 强制使用系统 unzip：export COMPOSER_DISABLE_TTY=1 && export COMPOSER_NO_INTERACTION=1（避免 PHP zip 扩展 fallback）
– 对大型 monorepo，改用 composer install --prefer-dist --optimize-autoloader
– 避免在 composer.json 中写死 dev-master 或 commit-hash，这会导致无法命中缓存
真正影响下载速度的，从来不是线程数，而是网络路径、镜像可用性、缓存命中率和文件系统 IO 能力。别迷信“多线程”，先检查 ~/.composer/cache 是否可写、镜像是否响应正常、PHP 的 openssl 和 curl 扩展是否完整——这些比调参数更容易被忽略。
