Composer 的镜像源优先级其实特别简单——就是 repositories 数组里从上到下的书写顺序，没有别的花招。它不支持什么“权重”、“分组”或者“条件路由”，Composer 只会线性扫描这个数组，第一个返回匹配包的源就直接锁定使用，后面的源压根不会触发请求。
镜像源优先级就是 repositories 数组的书写顺序，没有其他配置方式。 Composer 不支持“权重”“分组”或“条件路由”，它只按数组从上到下线性扫描，第一个返回匹配包的源就锁定使用，后续源完全不触发请求。
为什么改了 repositories 顺序却没生效
这是最常见的情况：你只改了全局 ~/.composer/config.json，但项目根目录的 composer.json 里也定义了 repositories——此时项目级配置永远覆盖全局配置。另一个高频原因是：你加了国内镜像，但没禁用 packagist.org，结果 Composer 仍会把官方源当兜底，导致部分包走镜像、部分走官方，看起来“优先级混乱”。
- 检查是否在项目
composer.json里重复定义了repositories，删掉或合并 - 确认是否显式设置了
"packagist.org": false；否则即使你把阿里云镜像放第一，Composer 在镜像 404 或超时后仍会 fallback 到官方源 - 运行
composer config repositories查看当前实际生效的源列表和顺序
type: "composer" 镜像源必须可索引，不能只是个 HTTP 目录
国内常用镜像（如阿里云、腾讯云）都是完整 type: "composer" 服务，提供 packages.json 索引文件。如果你自己搭了个静态 HTTP 服务，只放了 .zip 包但没生成索引，Composer 会直接报 Could not find package，不会尝试下一个源。
- 镜像源 URL 必须指向一个合法 Composer Repository 服务，能响应
/packages.json和/p/{vendor}/{package}.json这类路径 - 不要用
type: "vcs"指向 Git 仓库来“模拟镜像”，它不缓存版本列表，每次composer update都要远程探测 tag，且无法命中非 tag 版本（如dev-main） - 若镜像同步有延迟（新包发布后几分钟内查不到），不是 Composer 配置问题，而是镜像服务本身未及时拉取
多个镜像共存时，404 和超时行为完全不同
Composer 对不同错误码的处理逻辑不一致：404 会立即跳到下一个源；但 DNS 失败、连接超时（默认 30 秒）、HTTP 500 等会导致整个命令卡住或失败，根本不会查第二个源。
- 把最稳定、最快响应的镜像放在第一位（比如阿里云通常比某些小众镜像更可靠）
- 避免把需要认证的私有源和公开镜像混在同一数组——一旦私有源因
auth.json缺失而卡在 401，整个安装流程就中断 - 生产环境建议只配一个主力镜像 +
"packagist.org": false，而不是堆砌多个“以防万一”，因为多源不等于高可用，反而增加不可控延迟
真正容易被忽略的是：镜像源的可用性 ≠ Composer 的健壮性。你无法靠调整 repositories 顺序解决网络层问题，也不能指望 Composer 自动重试或降级。它只做一件事——按序找包，找到就停。
