Composer安装慢90%因镜像未生效，必须严格配置repo.packagist键名、补全"type":"composer"字段、URL末尾加/，再执行composer clear-cache并用composer install -vvv验证日志是否含镜像域名。
Composer安装慢，90%不是你网络差，而是镜像根本没生效——repo.packagist写错、composer type值漏掉、URL末尾少/，三者任一出错都会静默 fallback 到 packagist.org，卡在 Loading composer repositories 或 Downloading 阶段。
确认镜像是否真被 Composer 读取
别信“我执行过了”，只看这一行输出：
composer config -g repo.packagist
✅ 正确结果必须是完整 JSON：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}
❌ 空、null、https://packagist.org 或报错，说明配置失败。常见原因：
- 键名写成
repos.packagist（多一个s），新版 Composer ≥2.2 会静默忽略 - 漏掉中间的
composer参数：composer config -g repo.packagist https://...❌，必须是composer config -g repo.packagist composer https://...✅ - URL 少了结尾斜杠：
https://mirrors.aliyun.com/composer→ 拼出非法路径，部分版本直接 404 - 在 CI 或宝塔面板里运行，但配置写到了你自己的用户目录，而实际执行的是
www或runner用户
清缓存比换源还关键
镜像配得再准，vendor/ 和 composer.lock 里还存着旧包的 dist URL，Composer 会优先复用它们——结果就是“看着走镜像，实则仍连 packagist.org”。
必须执行这三步：
-
composer clear-cache：删掉本地元数据缓存 -
rm -rf vendor/ composer.lock：清除项目级残留 -
composer install -vvv 2>&1 | grep "Downloading"：观察日志中是否出现mirrors.aliyun.com或mirrors.huaweicloud.com
如果日志里还有 packagist.org，说明没清干净或配置未生效。
并发下载不调等于白配镜像
Composer 2.2+ 默认只开 3 个并发连接，严重浪费国内带宽。不改这个，换阿里云也卡。
加这行命令提升吞吐：
composer config -g parallel-downloads 10
注意：
- 旧版 Composer（composer config -g concurrent.http.max-parallel-downloads 10
- 搭配
prefer-dist true（避免从 Git 克隆源码包）更稳：composer config -g prefer-dist true - 设完立刻
composer clear-cache，否则新参数不加载
项目级配置有时比全局更可靠
团队协作、CI/CD 或宝塔面板场景下，全局配置容易因用户身份错位失效。项目级配置可提交进 Git，行为一致。
进项目根目录后运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会安全合并进 composer.json 的 repositories 字段。但要注意：
- 如果
composer.json里repositories是数组[]，命令会失败，需先手动改成对象{} - 若已有私有源（如 GitLab 私仓），该命令不会覆盖，只会新增或更新
packagist条目 - 项目级配置优先级高于全局，一旦存在，
composer config -g repo.packagist的输出就不再反映实际行为
最易被忽略的一点：镜像只加速「下载」，不解决「依赖解析」本身慢的问题。如果卡在 Resolving dependencies，那和网络无关，要查 PHP 版本兼容性、composer.json 中约束过严或循环 require。
