Composer怎么优化大型项目的安装速度_Composer如何通过并行下载和缓存优化几百个包的安装时间【技巧】

根本原因是默认串行解析依赖、频繁查 packagist.org 和重复解压 zip 包；开启 COMPOSER_PARALLEL_DOWNLOADER、复用 ~/.composer/cache/ 缓存、确保 composer.lock 提交并统一 Composer 2.x 可显著提速。

为什么 composer install 在大型项目里慢得像在编译内核

根本原因不是网络差，而是默认串行解析依赖 + 每次都查 packagist.org + 重复解压 zip 包。几百个包时，HTTP 请求堆积、PHP 进程反复 fork、磁盘 I/O 成瓶颈。尤其当 vendor/ 为空从头装，composer.lock 里哪怕只多一个 dev-main 分支的包，都可能触发全量重下载。

开启并行下载：用 COMPOSER_PARALLEL_DOWNLOADER 环境变量

Composer 2.2+ 原生支持并行下载，但默认关闭。不设环境变量，它就老老实实一个包一个包下。

• Linux/macOS：运行前加 COMPOSER_PARALLEL_DOWNLOADER=10 composer install（数字建议 5–15，太高反而触发 GitHub API 限流）
• Windows cmd：用 set COMPOSER_PARALLEL_DOWNLOADER=10 && composer install
• 注意：该变量对 composer update 同样生效，但更新时并行收益略低，因要反复计算依赖图
• 如果遇到 GitHub API rate limit exceeded，说明并行数超了，降为 5 或配 github-oauth

复用缓存：别让每次 CI 都重下一遍 vendor/

CI 环境最常见误区是清空 vendor/ 再装——这等于放弃所有本地缓存。Composer 缓存存在 ~/.composer/cache/，包含已下载的 zip、dist 包和 dist 的哈希校验文件。

• CI 脚本里加 composer install --no-interaction --prefer-dist --optimize-autoloader，确保走缓存路径
• 务必保留 ~/.composer/cache/ 目录（GitLab CI 用 cache:，GitHub Actions 用 actions/cache action）
• 避免用 --prefer-source：它绕过缓存，直接 clone git 仓库，速度慢且不稳定
• 如果项目用了私有包，确认 composer config --global repo.packagist.org.allow-plugins true（Composer 2.2+ 默认禁用插件，可能卡住私库认证）

composer.lock 文件本身就能提速

很多人以为 lock 文件只是“锁定版本”，其实它是安装加速器——没有它，Composer 必须在线解析整个依赖树；有它，就直接按记录的 dist URL 和 SHA256 下载。

• 确保 composer.lock 提交进 Git，且每次 composer update 后都提交更新后的 lock 文件
• 避免手动编辑 lock 文件：格式敏感，错一个逗号会导致 install 失败并回退到慢速解析模式
• 若团队混用 Composer 1.x 和 2.x，lock 文件格式不兼容，会强制重新 resolve——统一升级到 2.x 是底线

真正拖慢大型项目的，往往不是某一行命令，而是缓存没挂上、并行数瞎设、或者 lock 文件被忽略。这些点不处理，光换镜像源也救不了。