Composer不支持多镜像负载均衡，仅按repositories数组顺序线性查找，遇200即锁定该源，404才试下一个；超时或错误直接退出，需外部脚本探测切换并清缓存。
Composer 不支持多镜像源负载调度，也不存在“自动选最快”“轮询”或“故障转移”机制——这不是配置没写对，而是它根本没这个功能。
为什么 composer config -g repo.packagist 只能设一个镜像
这个配置项是单值字段，底层只绑定一个 RepositoryInterface 实例。反复执行：composer config -g repo.packagist https://mirrors.aliyun.com/composer/composer config -g repo.packagist https://mirrors.tencent.com/composer/
后者会直接覆盖前者，不会叠加、不会报错、也不会 fallback。
repositories 数组不是负载均衡，只是线性查找顺序
你在 composer.json 里写多个 {"type": "composer", "url": "..."} ，Composer 的行为是：
- 按数组从上到下请求每个源的
/packages.json - **只要某个源返回 HTTP 200 + 合法 JSON（哪怕不含你要的包），就立刻锁定该源，后续所有源都不再访问**
- 仅当该源对目标包明确返回
404时，才尝试下一个 - 遇到
timeout、502、DNS failed、500等，直接报错退出，根本不会查下一个
真要容灾，得靠外部脚本探测 + 切换 + 清缓存
所谓“高可用”，必须跳出 composer.json 配置幻想，用实际可执行的控制流：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
curl -I https://mirrors.aliyun.com/composer/packages.json探活，检查是否返回200 - 若失败，再探
https://mirrors.tencent.com/composer/packages.json - 探测成功后，执行
composer config -g repo.packagist <可用镜像> - 务必
rm -rf vendor composer.lock，否则旧锁文件仍指向失效源 - CI/CD 中建议封装成
~/bin/composer-safe-install这类可复用脚本
最容易被忽略的三个硬性条件
哪怕你把阿里云、腾讯云、官方源全写进 repositories，只要漏掉以下任一，镜像就形同虚设：
-
"packagist.org": false必须作为独立键写在composer.json根节点（不是塞进repositories里） - 所有自定义源必须是
"type": "composer"，不能混用vcs或artifact - 末尾加兜底项
{"type":"composer","url":"https://packagist.org/","packagist": true}是为了元数据回退，不是为了下载 ZIP —— ZIP 仍走第一个镜像，前提是它有
