Composer不支持多个packagist镜像自动fallback，因packagist.org是全局唯一元数据源，重复声明同类型仓库会报Invalid repository type；可靠切换仅三种：全局换源（需清缓存）、项目级锁定、单次--repository覆盖。
Composer不支持多个packagist镜像自动fallback
直接在repositories里并列写两个{"type": "composer", "url": "https://..."}，Composer会报错Invalid repository type——它把packagist.org视为全局唯一元数据源，重复声明同类型就拒绝加载。所谓“自动切换”是常见误解，官方从未实现主备探测+降级逻辑。
项目级多源配置只对非packagist包有效
如果你真在composer.json里写了多个composer类型源，Composer 2.2+ 会静默忽略除第一个外的所有项；但若你混用不同类型（比如一个composer镜像 + 一个package私有包定义），则优先级按数组顺序生效：
- 第一个
composer源仅用于查找packagist.org上有的包，不负责失败后跳转 - 私有
package或vcs源只查自己声明的包名，和镜像无关 -
"canonical": true仅影响包名解析路径，不能触发URL重试
真正能落地的“切换”只有三种手动方式
别被“多活”“高可用”这类词带偏，实际可用路径非常有限：
- 全局换源：运行
composer config -g repositories.packagist.org '{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}'，再立刻执行composer clear-cache——漏清缓存，90%概率仍走旧源 - 项目级锁定：进项目目录后运行
composer config repo.packagist composer https://mirrors.tencent.com/composer/（无-g），它会写入composer.json的repositories字段，且优先级高于全局配置 - 单次覆盖：用
--repository参数，如composer update --repository=https://packagist.mirrors.ustc.edu.cn，不改任何配置，但只作用于当前命令
CI/CD中模拟主备必须绕开Composer自身机制
在Docker或GitHub Actions里，靠composer config切源常失效，因为缓存复用、HTTP连接池残留或vendor目录污染会让请求继续发往已不可达的镜像。可靠做法是用shell脚本控制：
- 先
curl -I -s -f -o /dev/null https://mirrors.aliyun.com/composer/packages.json探测可用性 - 失败则切到腾讯云：
composer config -g repositories.packagist.org '{"type": "composer", "url": "https://mirrors.cloud.tencent.com/composer/"}' - 无论成功与否，都强制
composer clear-cache，否则旧元数据还在内存里
URL结尾必须带/，少一个字符就会触发Invalid repository type；清华旧源https://packagist.phpcomposer.com已下线，继续用会卡在cURL error 60。
