Composer 默认下载慢的根本原因是串行请求 Packagist，依赖树深时网络等待被放大，且直连境外源会叠加 DNS 解析慢、TLS 握手延迟等问题；启用国内镜像、--prefer-dist、调高并发及缓存复用可显著加速。
Composer 默认下载为什么慢
根本原因是 composer install 默认串行请求 Packagist（或镜像），每个包的元数据获取、zip 下载、解压、安装都按顺序排队，尤其在依赖树深、包数量多（如 Laravel + 大量插件）时，网络等待时间被放大。另外，若未配置国内镜像，直连境外 Packagist（packagist.org）还会叠加 DNS 解析慢、TLS 握手延迟、CDN 路由绕行等问题。
启用并行下载：require --prefer-dist + 并发数调优
Composer 本身不提供“多线程下载”开关，但可通过组合配置显著提升并发度：
-
composer config -g repos.packagist composer https://packagist.phpcomposer.com（旧镜像已停，改用：composer config -g repo.packagist composer https://packagist.org→ 实际应配国内镜像，如清华源：composer config -g repo.packagist composer https://packagist.phpcomposer.com已失效，正确命令是：composer config -g repo.packagist composer https://packagist.proxy.fly.dev或https://mirrors.aliyun.com/composer/） - 强制走 dist 包（跳过 git clone）：
composer install --prefer-dist—— 这能避免大量 git 协议开销，尤其对含大量git@源的私有包要谨慎，可局部加"preferred-install": {"your-vendor/*": "source"} - 调高并发连接数（PHP 7.4+）：
composer config -g github-protocols https git（减少协议协商）；更关键的是设置环境变量：export COMPOSER_PROCESS_TIMEOUT=2000和export COMPOSER_HOME=/path/to/cache（确保缓存复用）
vendor 目录加速的真正瓶颈常不在下载本身
很多用户发现即使换了镜像、加了 --prefer-dist，autoload_classmap.php 生成或 vendor/bin 脚本软链仍卡住——这是因为 Composer 在安装后会执行 dump-autoload 和脚本钩子（如 post-install-cmd）。这些是 PHP 单进程操作，无法并行。
- 跳过自动加载优化（开发期可接受）：
composer install --no-autoloader，之后手动跑composer dump-autoload --optimize（注意：--optimize 仅对 PSR-0/4 有效，Laravel 项目慎用） - 禁用非必要脚本：
composer install --no-scripts，尤其避开那些调用php artisan optimize或前端构建的钩子 - 检查
composer.json中是否误配了大量repositories，每个多余源都会触发一次元数据探测请求，拖慢整体流程
CI/CD 场景下 vendor 加速最有效的三件事
在 GitHub Actions、GitLab CI 等环境，磁盘 I/O 和网络是主要瓶颈，靠单机配置收效有限：
- 复用
vendor缓存：GitHub Actions 可用actions/cache@v3缓存vendor/目录，key 基于composer.lock的 hash（${{ hashFiles('**/composer.lock') }}），比重装快 5–10 倍 - 预构建基础镜像：Docker 构建中把
composer install --no-dev放到基础层，应用层只 COPY 代码，避免每次重复解析依赖 - 用
composer install --ignore-platform-reqs跳过扩展检测（仅限容器内已确保扩展齐全时），省去ext-xxx检查耗时
真正卡住的往往不是「怎么并行」，而是没意识到 vendor 里混进了大体积资源包（如 laravel/horizon 带前端 assets）、或某私有包的 dist URL 返回了 302 重定向——这种问题得靠 composer install -v 看具体哪个包 hang 住，再针对性处理。
