根本原因是Composer默认单线程下载+国内DNS/TLS延迟高，需换阿里云镜像、禁用DNS缓存、启用parallel-downloads=10、CI时加--no-autoloader--no-scripts。
为什么 Composer install 会卡在 downloading（尤其是 vendor 包）
根本原因不是网络差，而是 Composer 默认用单线程顺序下载，每个包必须等前一个解压完才开始下一个；加上 Packagist 官方源在国内 DNS 解析慢、TLS 握手延迟高，实际是「串行 + 高延迟」双重拖慢。更麻烦的是，composer install 还会同步校验 composer.lock 中所有包的 hash，哪怕只改了一行依赖，也要重走整套流程。
换国内镜像源 + 强制跳过 DNS 缓存
Packagist 官方源（https://packagist.org）直连基本不可用。必须切到国内镜像，但光改 repositories 不够——PHP 的 cURL 默认会复用 DNS 缓存，导致镜像域名解析仍走海外节点。
- 执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（阿里云镜像最稳） - 加环境变量绕过 DNS 缓存：
export COMPOSER_NO_INTERACTION=1 && export COMPOSER_HOME=~/.composer，再运行命令 - 如果用 Docker，记得在
Dockerfile里提前RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，否则每次构建都重新拉源
启用 parallel-downloads 并调高并发数
Composer 2.2+ 原生支持并行下载，但默认关闭且并发数保守（仅 3）。不开它，install 和 update 都没法真正提速。
- 全局启用：
composer config -g parallel-downloads 10（设为 10 是多数机器的合理上限，太高反而因 I/O 瓶颈变慢） - 注意：这个配置只对
composer install有效，composer update仍部分串行（因为要计算依赖图），别指望它也快 3 倍 - 若遇到
file_put_contents(/tmp/...): failed to open stream错误，说明并发过高触发临时文件竞争，降到6或8
跳过 autoload 生成和脚本执行（仅限 CI 或部署阶段）
开发时需要自动加载和 post-install-cmd 脚本，但 CI 构建或生产部署时，这些纯属冗余开销，尤其当项目含大量第三方包时，composer install --no-autoloader --no-scripts 可省下 30%+ 时间。
-
--no-autoloader跳过生成vendor/autoload.php，后续自己用composer dump-autoload --optimize单独处理 -
--no-scripts阻止执行post-install-cmd等钩子，避免意外触发前端构建、缓存清理等重型操作 - 注意：这样装出来的
vendor不能直接跑 PHP，必须补一次composer dump-autoload --optimize才能用
真正卡点往往不在下载本身，而在 lock 文件校验、autoloader 重建、以及没关掉的 post-update-cmd 脚本。调并发、换镜像只是基础，得结合场景关掉非必要环节，才能把 5 分钟压到 1 分半。
