Composer并行执行：开启多线程模式极速获取依赖包

Composer并行执行：开启多线程模式极速获取依赖包？先别急着找开关

首先得澄清一个常见的误解：Composer本身并没有一个所谓的“多线程模式”需要你去开启。它实现的“并行下载”本质上是并发HTTP请求，而非操作系统级别的多线程。如果你在命令行里苦苦寻找 --threads 或 -j 这类参数，结果只会得到一个 Unrecognized option 的错误提示。

事实上，从 Composer 2.1 版本开始，并发下载功能就已经默认启用了，根本无需额外操作。如果你感觉下载还是慢得像在“单线程爬行”，那问题很可能出在其他地方。

composer install 还在一行一行下载？先确认是否真卡在下载

感觉慢，不一定就是下载的锅。很多开发者一看到进度条蠕动，就下意识地认为是并发没开。其实，真正的瓶颈可能藏在别处。一个简单的诊断方法是加上 -v（详细）参数运行 composer install -v，观察日志输出。

如果日志卡在 Generating autoload files 或者某个 post-install-cmd 脚本上，那么你就算把并发数调到天上去，也解决不了问题。只有当屏幕上连续出现多行 Downloading https://... 的提示，并且每一行都进展缓慢时，才说明下载环节确实是速度瓶颈。

• 默认已是并发：Composer 2.1+ 版本默认就使用了基于 curl_multi 的并发请求机制，不需要你手动开启。
• 串行的假象：如果表现依然像单线程，大概率是这三个原因：使用的镜像源响应太慢、DNS解析卡住了，或者访问GitHub API时被限流（尤其是没配置token的情况下，每小时请求数限制很低）。
• 一个小优化：执行 composer config --global github-protocols https，可以避免SSH认证可能带来的阻塞。

parallel-downloads 配置只对 dist 包生效，且有实效上限

Composer 2.2+ 版本引入了一个实验性配置项：parallel-downloads。需要明确的是，它控制的是最大并发HTTP请求数，而不是系统线程。这个值并非越大越好，设得太高容易触发目标服务器的限流机制，或者导致本地资源竞争；设得太低，又白白浪费了带宽潜力。

• 黄金数值：通常推荐设置在 6 到 8 之间。可以通过全局配置命令设定：composer config -g parallel-downloads 6。
• 重要限制：这个配置仅对通过 --prefer-dist（默认方式）下载的压缩包生效。如果你使用 --prefer-source 从Git仓库克隆代码，那么它完全不起作用。
• 冲突信号：如果安装过程中间出现类似 file_put_contents(/tmp/): failed to open stream 的错误，这很可能是临时文件句柄竞争导致的，尝试将并发数降低到 4 通常能解决问题。
• CI环境建议：在持续集成环境中，最好固定这个值，避免因为不同构建机环境的差异，导致构建速度时快时慢。

hirak/prestissimo 插件只适用于 Composer 1.x，2.x 用户必须卸载

对于还在使用 Composer 2.x 的用户，有一个至关重要的清理动作：卸载 hirak/prestissimo 插件。这个在1.x时代被誉为“下载加速神器”的插件，与2.x版本的内置并发机制并不兼容。强行使用可能导致依赖解析异常、composer.lock 文件结构错乱，甚至静默失效，让你以为加速了，实则埋下了隐患。

• 立即卸载：Composer 2.5+ 用户请运行：composer global remove hirak/prestissimo。
• 验证清理：执行 composer global show，确保插件列表里已经没有了它的身影。
• 历史项目处理：如果项目早期是用 Composer 1.x 配合 prestissimo 安装的，升级到 2.x 后，最稳妥的做法是删除 vendor/ 目录和 composer.lock 文件，然后重新运行 composer install。
• 认清能力边界：必须明确，这类插件从来都不能加速自动加载文件的生成或者脚本的执行。这些环节始终是单线程处理的，别指望它能解决所有性能问题。

真正影响速度的，往往是镜像、缓存和 PHP 环境配置

说到底，比起单纯调高一个并发数字，更根本的优化在于确保每一次网络请求都尽可能快、稳、少重试。对于国内开发者而言，不更换到高速镜像源，就算开出20个并发，体验也依然是“原地踏步”。

• 换源是首要任务：立即配置国内镜像，例如阿里云：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。
• 定期清理缓存：运行 composer clear-cache，陈旧的缓存元数据可能导致Composer反复尝试失败的请求。
• 检查PHP扩展：确保cURL扩展已启用（php -m | grep curl），这是并发下载的基石，没有它，一切并发都会退化成串行。
• CI环境优化：在持续集成脚本中，可以加上 --no-scripts --no-autoloader --no-dev --optimize-autoloader 等参数，跳过所有非必要的安装后步骤，大幅缩短构建时间。

可以这么说，并发数、镜像源、缓存状态、PHP扩展，这四者构成了Composer下载速度的“稳定四边形”。缺了任何一个角，其他方面的优化效果都会大打折扣。系统性地检查这四点，才是解决下载慢问题的正道。