Composer不支持多镜像自动fallback，因repo.packagist.org为单值配置且全局覆盖，repositories数组仅用于元数据合并而非下载重试，真容灾需外部脚本探测+切换+清缓存。
Composer 本身不支持多个镜像源自动切换，所谓“主备 fallback”必须靠外部脚本控制流程，不能靠 repositories 数组或 composer config 多次设置实现。
为什么 composer config -g repo.packagist.org 只能设一个 URL
这个配置项是单值字段，底层对应 Packagist 的唯一替换地址。执行两次 composer config -g repo.packagist.org https://a.com 和 composer config -g repo.packagist.org https://b.com，后者会直接覆盖前者——不是叠加，也不报错。官方明确拒绝在核心中加入多源 fallback（GitHub issue #8729），这不是 bug，是设计决定。
常见错误：用空格拼两个地址，如 composer config -g repo.packagist.org https://a.com https://b.com，命令会失败或只生效第一个。
- 参数差异：
repo.packagist.org接收纯字符串，不是数组、JSON 或 URL 列表 - 兼容性：所有 Composer 2.x 版本行为一致，不存在“某个版本突然支持”的情况
- 容易踩的坑：改完没生效，往往是因为没加
--global，或项目级composer.json里已定义repositories，导致全局配置被完全忽略
为什么 repositories 数组不是 fallback 机制
你在 composer.json 里写多个 {"type": "composer", "url": "..."} ，Composer 不会在下载失败时重试下一个源。它只做两件事：1）按数组顺序请求每个源的 packages.json，合并成一张索引表；2）安装时，从第一个声明了该包完整版本信息的源拉 ZIP 包，其余源完全不参与下载阶段。
常见错误现象：composer install 卡在私有源超时，不自动切到阿里云镜像；Could not find package xxx 报错，其实是因为私有源排在后面，而包名和公共包冲突，Composer 根本没查它。
- 必须显式关闭默认源：
"packagist.org": false要作为独立对象写在repositories数组末尾，否则 Composer 仍会偷偷连官方站 - 兜底源必须放最后：
{"type": "composer", "url": "https://packagist.org/", "packagist": true}放数组末尾，且前面所有镜像都得是composer类型，否则元数据合并会出错 - 性能影响：每个
repositories都要单独请求元数据，不共享缓存，多了反而变慢
真·容灾：用脚本实现探测 + 动态切换 + 清缓存
CI/CD 或本地开发中防止单点失效，唯一可靠路径是三步外部控制流：探测镜像根路径是否可访问 → 切换当前生效源 → 清缓存避免旧元数据干扰。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
探活命令示例：curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json，返回 200 才认为可用。
动态写入项目级配置：composer config repositories.packagist composer https://mirrors.tencent.com/composer/，这条命令会新增或覆盖 repositories.packagist 条目（注意不是 repositories.0）。
- 切换后务必运行
composer clear-cache，否则旧镜像的元数据可能残留，导致后续请求返回404 - 如果项目里已有
repositories，脚本需先读取原始结构，仅替换镜像 URL，避免误删私有源 - 临时切镜像（仅本次命令）可用环境变量：
COMPOSER_REPO_PACKAGIST=https://packagist.phpcomposer.com composer install，但新版 Composer 对该变量支持不稳定，不推荐用于 CI
更稳的做法：只配一个带服务端 fallback 的镜像代理
与其折腾本地多源逻辑，不如直接指向一个由服务商实现故障自动切换的镜像站，比如 https://mirrors.tencent.com/composer/。它的服务端会在自身不可用时自动回退到官方源或其它备用节点——这层逻辑你不用管，也无需在本地做探测。
对比之下，自己写脚本探活虽可控，但容易漏掉缓存清理、权限问题、Docker 层缓存复用等边界场景。尤其在 CI 中，vendor 目录复用、HTTP 缓存未清、或镜像返回 503 后未重试，都会让 fallback 失效。
容易被忽略的关键点：即使你写了完整的探测 + 切换脚本，只要没在每次 composer install 前强制清缓存，就可能因为旧 packages.json 里的 dist URL 还指向已宕机的源，导致下载阶段直接失败——这个环节不在探测范围内，却决定成败。
