Composer不支持多镜像自动fallback，优先级仅由repositories数组顺序决定：仅当首个源返回404时才尝试下一个，超时或500等错误直接中断；常见失效原因是未禁用packagist.org或项目级配置覆盖全局。
Composer 不支持“多镜像自动 fallback”，所谓优先级就是 repositories 数组的书写顺序——从上到下线性扫描，第一个返回有效包元数据（且非超时/500）的源就锁定使用，后面的全跳过。
为什么改了 repositories 顺序却没走镜像
最常见原因是项目级 composer.json 覆盖了全局配置，或者没禁用 packagist.org 导致兜底行为。Composer 默认把 packagist.org 当作隐式最高优先级源，哪怕你把阿里云镜像写在第一位，只要它对某个包返回 404，Composer 就立刻切到官方源，看起来像“优先级失效”。
- 运行
composer config repositories查看当前实际生效的源列表和顺序，别靠猜 - 确认项目根目录
composer.json中是否也定义了repositories：有则优先生效，全局配置（~/.composer/config.json）完全被忽略 - 必须显式加上
{"packagist.org": false}，且放在repositories数组末尾（不是开头），否则官方源仍会偷偷触发请求 - 删掉
vendor和composer.lock后重跑composer install，避免旧 lock 文件记录的是官方源 hash
repositories 数组里多个镜像能自动切换吗
不能。Composer 对错误的处理逻辑是分情况的：遇到 404 会继续查下一个源；但 DNS 失败、连接超时（默认 30 秒）、HTTP 500 等，直接报错退出，根本不会尝试第二个源。
- 把响应最快、稳定性最高的镜像（如
https://mirrors.aliyun.com/composer/）放在数组第一位 - 腾讯云等备用镜像可以放第二位，但仅当第一位明确返回 404 时才启用——不是“网络不通就切”，而是“包不存在才切”
- 千万别把
https://repo.packagist.org/和镜像 URL 同时塞进数组：前者会抢在镜像前发请求，失败即中断 - 生产环境建议只配一个主力镜像 +
{"packagist.org": false}，堆砌多个源不提升可用性，反而增加不可控延迟
私有源和公开镜像混配时要注意什么
私有包必须声明在 repositories 数组最前面，否则会被公开镜像截断——因为 Composer 是短路匹配，一旦镜像返回了同名包（哪怕版本不对），就不会再查后面的私有源。
- 自定义私有源必须带
"type": "composer"和完整可访问的url，缺一不可 - 避免把需要认证的私有源和公开镜像混在同一数组：若
auth.json缺失，私有源卡在 401，整个流程中断 - 国内镜像本质是只读代理，不托管私有包；混配时必须禁用
packagist.org，否则私有包可能被跳过 - 镜像同步有延迟（新包发布后几分钟内查不到），这不是配置问题，而是镜像服务本身还没拉取完成
真正容易被忽略的是：镜像源的可用性 ≠ Composer 的健壮性。你看到的“连不上”，大概率不是配置顺序错了，而是第一个源返回了超时或 500，而不是 404——这时候 Composer 根本不会往下走，再多镜像也没用。
