Composer如何利用并行下载插件提高安装速度（加速插件）-composer-PHP中文网

composer 2.1+ 原生支持并行下载，无需插件；确认方式为执行 composer install -vvv 观察多 url 同时下载或进度快速跳变，且版本 ≥2.1、禁用 hirak/prestissimo、配置 http-max-concurrent-downloads 并搭配阿里云镜像与 clear-cache。

composer如何利用并行下载插件提高安装速度（加速插件）

hirak/prestissimo 已彻底失效，别装它，也别找“兼容方案”。 Composer 2.1+ 原生支持并行下载，插件反而会静默降级为串行、破坏 composer.lock 结构。

怎么确认并行下载真在跑

不看配置项有没有写，只看日志是否动态并发：composer install -vvv 运行时，若同时出现多行 Downloading https://mirrors.aliyun.com/，或进度显示类似 Downloading (7/42) → (12/42) 快速跳变，说明已激活。

如果始终单行打印、卡在某个包不动，大概率是镜像响应慢或被限流，不是并发没开。

执行 composer --version，输出必须是 Composer version 2.1.x 或更高；低于此版本（如 1.10.22）压根不支持原生并行
composer diagnose 若仍提示 hirak/prestissimo，说明插件残留，必须先运行 composer global remove hirak/prestissimo
检查 PHP 是否启用 curl 扩展：php -m | grep curl，没启用会退化为串行且不报错

`http-max-concurrent-downloads` 是唯一有效的并发配置

parallel-downloads 已在 Composer 2.2+ 中弃用，设了也不生效，还可能误导你。真正起作用的是 http-max-concurrent-downloads，它直接控制 HTTP 请求池大小。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

全局设为 8（多数机器的稳妥上限）：composer config -g http-max-concurrent-downloads 8
值不是越高越好：设成 20 容易触发 file_put_contents(/tmp/): failed to open stream（临时文件竞争），阿里云/腾讯云镜像在 >12 并发时也常返回 429 Too Many Requests
该配置只对 composer install 生效；composer update 因需实时解析依赖图，元数据拉取（如 packages.json）仍是串行，无法提速

镜像源没换，调再高也没用

并发只是“同时发请求”，如果每个请求都卡在 DNS 解析、TLS 握手或首字节延迟上，开 10 个线程等于 10 个排队窗口。

换源命令必须带 composertype 参数：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
换源后必须执行 composer clear-cache，否则旧包可能仍走原源
某些企业网络复用 cURL 的 DNS 缓存，导致镜像域名解析仍走海外节点；可加环境变量绕过：export COMPOSER_NO_INTERACTION=1

私有 Git 包和 CI 场景下容易踩的坑

私有 GitLab/GitHub 包若未显式声明 dist 地址，--prefer-dist 会直接报错 Could not find a matching version of package xxx。

CI/CD 中必加的四个参数：--prefer-dist --no-dev --no-autoloader --no-scripts，跳过所有非必要环节。

--prefer-dist 强制走压缩包，避免 Git 克隆；但对 dev- 分支或 path 类型仓库无效，会 fallback 到 source
GitHub API 限流常见于未配 Token 的场景，现象是 Could not fetch https://api.github.com/: 403 rate limit exceeded，解法是 composer config -g github-oauth.github.com "your_token_here"
vendor 目录写入慢？关掉 fsync 和杀毒实时扫描——尤其 Windows Defender 或 macOS Time Machine 可能拦截每个 file_put_contents 调用

真正影响速度的从来不是“要不要并发”，而是“并发能不能落地”。镜像、版本、临时目录争抢、DNS 缓存、防病毒软件——这些点任何一个没对齐，http-max-concurrent-downloads 就只是个摆设。