Composer不支持主从热备，仅支持顺序尝试+显式降级；必须通过项目级composer.json或插件（如composer-plugin-mirror）实现fallback，且需满足URL格式、type类型、packagist.org禁用等硬性条件。
Composer 本身不支持主从热备式的镜像切换——它没有心跳检测、健康检查或自动故障转移机制。所谓“主从热备”，在 Composer 场景下是误用概念；实际能落地的只有顺序尝试 + 显式降级，且必须靠项目级 composer.json 或插件驱动。
为什么不能用“主从热备”思维配 Composer 镜像
Composer 的仓库加载逻辑是线性的：按 repositories 数组顺序逐个请求，只要第一个源返回 HTTP 200 + 有效 JSON（哪怕响应慢到 30 秒），就不会查第二个。它不判断“主是否存活”，也不做超时熔断后自动切“从”。常见误解包括：
- 以为把阿里云放前面、官方放后面就是“主从”，其实只是“优先级列表”
- 以为加了
"packagist.org": false就启用了高可用，其实这只是关掉了默认兜底行为 - 用
composer config -g repo.packagist写两次，结果第二次直接覆盖第一次，根本没“备”可言
真正生效的双镜像配置（项目级 composer.json）
必须满足三个硬性条件，缺一不可：
-
"packagist.org": false写在composer.json根节点，不能嵌套进repositories里 - 所有镜像都用
"type": "composer"，URL 末尾带/（如"https://mirrors.aliyun.com/composer/"） - 顺序即策略：最快最稳的镜像放数组首位，官方源放末位，仅当首位返回 404（包不存在）才继续查下一个
示例片段：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
{
"repositories": [
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"},
{"type": "composer", "url": "https://packagist.org/"}
],
"packagist.org": false
}
用 composer-plugin-mirror 实现类“热备”的 fallback
这是目前唯一接近“失败即切”的方案，但它依赖插件运行时干预，不是 Composer 原生能力：
- 安装：
composer global require yunwuxin/composer-plugin-mirror - 全局配置多个镜像时，键名按字母序排序，所以用
mirror1、mirror2控制顺序 - 每个镜像必须显式声明
"packages": ["*"]，否则只代理指定包名 - 超时默认 5 秒（非 Composer 默认的 30 秒），更适合快速降级
注意：该插件不修改 composer.json，但会绕过其 repositories 逻辑，优先走自己维护的镜像列表。
避免卡死和误判的关键操作
网络层问题常被当成镜像配置失败：
- 加
-vvv看真实请求域名，确认是否真走了你配的镜像 - 设环境变量
COMPOSER_IPV4=1强制 IPv4，避开 IPv6 握手延迟导致的“假超时” - 全局调高超时：
composer config -g http.timeout 600，防止因单个镜像慢拖垮整个流程 - CI/CD 中禁用交互：
composer install --no-interaction --prefer-dist，减少非必要阻塞
真正的高可用不在配置多几个 URL，而在明确知道哪个环节会失败、何时该放弃、以及失败后是否有确定的下一跳——Composer 的设计决定了它永远是个“顺序执行器”，不是“智能路由网关”。
