Composer 下载慢主因是直连 packagist.org 延迟高、丢包多，应切换阿里云镜像源并全局配置、清缓存；原生不支持多线程，可通过启用 HTTP/2、禁用进度条、优先 dist 包等优化；需检查 platform 配置与 autoload-dev 依赖，CI 中应缓存 Composer 自身缓存而非 vendor 目录。
Composer 下载慢是因为默认走 Packagist 官方源
国内直连 packagist.org 延迟高、丢包多，尤其下载 zip 包或大依赖时卡在 Downloading…… 或反复重试。这不是你网络差，是路由绕行和 CDN 覆盖弱导致的。
最直接有效的解法是切镜像源——但要注意：不是所有镜像都同步及时，也不是所有项目都能无感切换。
- 优先用
https://packagist.phpcomposer.com（已停更，别用）或当前稳定的是https://mirrors.aliyun.com/composer/ - 切源命令必须加
-g全局生效：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 如果项目里已有
composer.json里硬编码了repositories，全局配置会被覆盖，得手动删或改项目级配置 - 切完记得清缓存：
composer clear-cache，否则可能还在读旧包索引
Composer 多线程下载？原生不支持，但可间接提速
composer install 和 composer update 默认是串行下载 + 解压，没法开 -j4 这种参数。所谓“多线程”其实是靠并行安装多个包的 zip、并行执行脚本钩子，但底层仍受限于 PHP 的单进程 I/O 和 cURL 设置。
真正起效的提速点在底层网络和压缩处理：
- 启用
curl的 HTTP/2 支持（PHP 7.3+ + cURL 7.62+），加配置：composer config -g use-http2 true - 关掉进度条减少 I/O 开销：
composer install --no-progress - 用
--prefer-dist（默认）确保下 zip 包而非 git clone；若误配了--prefer-source，会巨慢 - 避免在 CI 环境中反复
composer update，应固定composer.lock并只跑install
vendor 目录太大 / 重复下载？检查 autoload 和平台配置
有时候你以为是下载慢，其实是每次都在重装 dev 依赖、或因平台版本不匹配反复回退安装。比如你在 PHP 8.2 上跑 composer install，但 composer.json 里写了 "platform": {"php": "7.4"}，Composer 就会去搜旧版包，甚至触发降级逻辑，拖慢整个流程。
- 运行
composer show --platform确认当前解析的 PHP 版本是否符合预期 - 删掉不必要的
platform配置，让 Composer 自动按真实环境选包 - 检查
autoload-dev是否引入了重型测试工具（如phpunit），它们不参与运行时，但会进 vendor 占空间、拉依赖链 - 用
composer why-not php:8.2快速定位哪个包卡着升级
CI/CD 中 Composer 构建慢？关键在缓存策略
GitHub Actions、GitLab CI 里反复 composer install 慢，90% 是没正确复用 vendor 缓存，或缓存了错误路径。
- 不要缓存整个
vendor目录——不同 PHP 版本、扩展、composer.lockhash 下内容不兼容 - 应缓存
~/.composer/cache（Linux/macOS）或%USERPROFILE%AppDataRoamingComposerCache（Windows） - CI 中加
--no-interaction --optimize-autoloader --classmap-authoritative，跳过交互、生成高效 autoload 映射 - 如果用了 Docker，把
composer install放到构建中间层，而不是每次 run 时执行
镜像源 + 缓存 + 精准平台配置，这三块对齐了，下载时间通常能从 3–5 分钟压到 30 秒内。最容易被忽略的是项目级 repositories 覆盖全局源，以及 platform 错配导致反复解析失败——这两处一查一个准。
