Composer不支持多镜像自动fallback，需手动在composer.json或config.json中用repositories数组配置多个源，设"packagist.org": false关闭默认源，并在末尾加"packagist": true兜底元数据。
composer config 命令怎么设置多个镜像源
Composer 本身不支持“同时启用多个镜像源并自动 fallback”的原生配置，config 命令只能写入单个 repositories.packagist.org 替换项。你执行 composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/，它只会覆盖前一个；反复执行只是不断替换，不会叠加。
真正能“多镜像”的方式是手动编辑 composer.json（项目级）或 auth.json 同级的全局 config.json（用户级），用 repositories 数组显式声明多个源，并把 packagist.org 置为 false 关闭默认源。
- 必须把
"packagist.org": false放在repositories顶层，否则 Composer 仍会偷偷访问官方源 - 数组顺序即优先级：越靠前的源匹配失败后才试下一个，但 Composer 不做“自动重试”——只有当某个包在第一个源返回 404（而非 502/超时）时，才会查下一个
- 所有自定义源必须带
"type": "composer"和有效"url"，缺一不可，否则composer update直接报错Invalid repository type
为什么 packagist.org 设为 false 后某些包装不上
不是镜像没同步，而是你漏掉了“元数据兜底”逻辑。国内镜像（如阿里云、腾讯云）只同步 packagist.org 的包列表和 ZIP 包，但不托管 packages.json 的完整索引快照——它们依赖上游定期拉取，而这个过程有延迟或丢包。
典型现象：composer require monolog/monolog 报 Could not find package monolog/monolog，但浏览器打开 https://mirrors.aliyun.com/composer/p2/monolog/monolog.json 又能正常返回。
- 根本原因是 Composer 在解析
packages.json时，先请求根索引（如/packages.json），再根据其中的providers-url拼子路径；镜像若未及时更新根索引，就会漏掉新发布包 - 解决办法：在
repositories数组末尾加一个"packagist": true条目（注意不是"packagist.org"），它会触发 Composer 回退到官方源查元数据，但 ZIP 包仍从你配的第一个镜像下载（只要那个镜像有） - 别写
"packagist": {"type": "composer", "url": "https://packagist.org"}—— 这样会强制走官方源下 ZIP，失去镜像加速意义
全局配置 vs 项目配置哪个更靠谱
全局配置（composer config -g）看似一劳永逸，实际在 CI/CD 或团队协作中极易引发隐性冲突。比如某台机器全局设了清华源，但项目 composer.json 显式写了阿里云镜像，Composer 会合并两者，导致源列表混乱、优先级错乱。
真实项目中，应以项目级 composer.json 的 repositories 为准，全局只保留最基础的认证或 proxy 设置。
- 项目配置可被 Git 跟踪，新人
git clone && composer install开箱即用，无需额外文档说明“请先配镜像” - 全局配置一旦出错（如误删
repositories字段），所有项目都会受影响；而项目配置出问题只影响当前目录 - CI 环境（如 GitHub Actions）默认无全局镜像，必须靠项目配置驱动，否则构建大概率因超时失败
HTTP 302 重定向会让镜像失效吗
会，而且非常隐蔽。部分镜像（尤其是早期自建源）用 Nginx 返回 302 跳转到真实存储地址，而 Composer 默认不跟随重定向（allow_url_fopen 关闭或 cURL 配置限制时尤其明显），结果就是 composer update 卡住或报 file could not be downloaded。
验证方法：用 curl -I https://mirrors.example.com/packages.json 查看响应头，如果含 Location: 且状态码是 302，基本就是它的问题。
- 临时绕过：在
config.json中加"http": {"max_redirects": 5}，但治标不治本 - 根本解法：换用直连型镜像（阿里云、腾讯云、华为云均属此类），或确认自建镜像已关闭重定向，改用
proxy_pass或对象存储直出 - 别信“镜像速度排行榜”里只测首页响应时间的结论——真正卡顿点往往在 ZIP 包下载阶段的重定向链路上
多镜像不是堆数量，关键在 packagist.org 的开关时机、repositories 数组的顺序控制、以及对重定向和元数据同步延迟的预判。这些细节不写进 composer.json 就等于没配。
