Composer不支持多镜像负载调度，仅按repositories数组顺序串行尝试，首个响应即用；所谓“fallback”实为失败重试（仅404跳转，超时/5xx即报错），无并发、无健康检查、无自动选优；真容灾需外部脚本或环境变量动态切换源。
Composer本身不支持多镜像负载调度
Composer没有内置的负载均衡、故障转移或轮询机制。所谓“多镜像环境”，实际只是配置多个repositories，但Composer按数组顺序依次尝试，遇到第一个能响应的就用它——不是并发拉取、不是权重分配、也不是健康检查后选最优节点。
你看到的“fallback”行为，本质是失败重试：如果阿里云镜像返回404或超时，Composer才会查下一个；而一旦第一个镜像返回200（哪怕慢），它就不会再碰后面的。
-
repositories数组里靠前的镜像优先级最高，顺序即策略 - 写
{"packagist.org": false}必须和镜像对象同级、同在repositories数组内，否则官方源仍会兜底触发网络请求 - 即使你写了两个国内镜像，比如阿里云+中科大，Composer也不会自动切到更快的那个——它只认第一个可用的
想实现类负载效果，只能靠外部控制
真正可控的方式是绕过Composer原生逻辑，在调用层做分发：
- CI/CD中用
COMPOSER_REPO_PACKAGIST环境变量动态注入不同镜像URL，配合灰度发布或地域路由逻辑 - Docker构建阶段，在
Dockerfile里用RUN composer install --repository=$MIRROR_URL --no-interaction，由构建系统传入MIRROR_URL参数 - 自建代理服务（如Nginx反向代理），把
https://repo.packagist.org统一转发到多个镜像节点，并在上游配置least_conn或ip_hash
注意：parallel-downloads参数和这个无关——它只控制单个镜像源内部的并发下载数，且在容器中容易因资源限制导致Too many open files错误。
为什么repositories里堆多个镜像反而更慢
常见误操作：在composer.json里写一堆镜像，以为能“自动选快的”。结果往往是：
- Composer对每个镜像都尝试请求
p2/元数据目录，哪怕只差毫秒也得等超时（默认30秒） - 第二个镜像不会并行发起请求，而是串行等待第一个彻底失败后才启动
- 若第一个镜像返回了部分数据但校验失败（如hash不匹配），Composer可能反复重试而非跳转
- 镜像URL末尾漏掉
/（如https://mirrors.aliyun.com/composer），会导致拼出/composerpackages.json404，白白耗尽超时时间
生产环境推荐的“伪负载”实践
最稳定的做法不是堆镜像，而是用单一高可用镜像 + 外部容灾：
- 首选
https://mirrors.aliyun.com/composer/——同步频率15分钟，CDN覆盖广，实测平均延迟 - 在Kubernetes中为
composer install加timeout: 600和重试逻辑（如backoffLimit: 2），比依赖多个镜像更可控 - CI中用
curl -I https://mirrors.aliyun.com/composer/packages.json预检镜像可用性，失败则切换备用域名（如中科大）并重新触发构建
真正的瓶颈从来不在“选哪个镜像”，而在配置是否穿透到所有执行上下文——Pod里没生效的config.json、Dockerfile里错位的USER、CI中被覆盖的环境变量，这些细节比镜像数量重要得多。
