Composer默认串行下载不是缺陷而是负载控制策略，因其HttpDownloader基于stream_context_create不支持并行，且并发会触发服务端限流或连接重置；加速关键在配置国内镜像、强制--prefer-dist、启用curl扩展。
Composer 默认串行下载不是性能缺陷，而是负载控制策略
Composer 不提供 --threads 或 --concurrency 参数，根本原因不在技术能力，而在服务端压力与客户端稳定性权衡。它的 HttpDownloader 基于 PHP 的 stream_context_create，天然不支持并行 HTTP 请求；即使强行 patch 改用 cURL multi，也会触发 Packagist 或镜像源的限流（如 429 Too Many Requests）或连接重置（Connection reset by peer）。国内企业内网镜像若不支持 Range 头，还可能返回 416 Requested Range Not Satisfiable 错误。
真正影响 Composer 安装耗时的，是 dist vs source + 镜像源延迟
实测表明：在同等网络条件下，--prefer-dist 比 --prefer-source 快 3–10 倍，因为 ZIP 包下载是单次大块传输，而 Git clone 需建立 SSH/HTTPS 连接、解析 refs、逐 object fetch，I/O 和 TLS 握手开销高得多。同时，未配置国内镜像时，packagist.org 的 DNS 解析和 TLS 握手常卡在 2–5 秒——这不是并发能解决的问题。
- 阿里云镜像：
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 config -g repo.packagist输出应为 HTTPS 地址，而非packagist.org
想“并发”，只能换 HttpDownloader 实现，但代价明确
官方不支持并发，但可通过替换 HttpDownloader 类（例如用 parallel-http 库）实现底层并发请求。这要求：
- PHP 必须启用
ext-curl（allow_url_fopen = On也建议保持） - 需手动修改
composer.json的autoload或使用插件机制注入新 downloader - 并发数设太高（如 >8）反而导致连接池耗尽、DNS 查询风暴、服务端拒绝响应
- 无法规避 Packagist 的 per-IP 请求频控，部分镜像会直接返回空响应或 503
服务器负载视角：Composer install 对 CPU/内存影响极低，瓶颈永远在 I/O 和网络
composer install 过程中，PHP 进程大部分时间阻塞在 socket read 上，CPU 占用通常低于 5%，内存增长主要来自解压 ZIP 和构建 autoload map。真正吃资源的是后续的 php artisan optimize 或 opcache.preload 编译——这些才是需要调优并发数的环节。如果你在 CI/CD 中发现 Composer 卡顿，优先检查：
- CI 机器是否启用了
ext-curl？没启用则 fallback 到 stream，更慢且无超时控制 - 是否在容器中运行？Docker 默认 DNS 配置可能导致域名解析延迟飙升
- 是否重复执行了
composer update？它会重新 resolve 所有依赖，比install耗时多 3–5 倍
并发调度本身对服务器负载影响微乎其微，但盲目追求“快”而忽略镜像源、dist 策略、扩展启用状态，反而会让问题更难定位。
