composer不支持自动镜像切换，无fallback、退避算法或运行时换源机制；仅当首个源对某包返回404时才查下一源，超时或5xx错误直接报错退出。
Composer 没有退避算法机制，也不做任何运行时镜像切换。
Composer 根本不实现 fallback 或重试换源
所谓“退避算法”是常见 HTTP 客户端（如 curl、Guzzle）或服务网格（如 Istio）里的概念，Composer 完全不包含这类逻辑。它只在解析阶段查一次 packages.json，然后按 repositories 数组顺序锁定一个源——仅当该源对某个包返回 404 时才看下一个；遇到 timeout、502、503、DNS 失败等，直接报错退出，不会尝试第二个源。
常见错误现象包括：
-
composer install卡在Downloading https://xxx.com/packages.json且超时后不换源 - 日志里出现
Failed to download xxx: The "https://mirrors.aliyun.com/composer/..." file could not be downloaded (HTTP/2 0)，但后续没任何 fallback 提示 - 把
https://packagist.org/和镜像 URL 并列写进repositories，结果因官方源排在前面反而优先触发失败请求
repositories 数组不是容灾列表，而是元数据匹配顺序表
Composer 把 repositories 当作静态元数据合并输入，不是运行时请求路由表。它会：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 依次请求每个源的
packages.json，合并所有包名+版本信息到一张本地索引表 - 对每个要安装的包，从数组第一个源开始查：如果该源声明了这个包（哪怕只有
v1.0.0），就锁定它，并用它的dist.url下载 ZIP - 只有当第一个源明确返回
404（注意：不是超时，不是500），才会查第二个源是否声明了该包
这意味着：
- 腾讯云镜像放在第二位，只会在阿里云镜像对某个包返回
404时启用——不是“阿里云挂了就切”，而是“阿里云说没这个包，腾讯云说有，才用腾讯云” - 如果你的私有包只在内部源注册，那无论镜像多快，都必须确保它排在
repositories第一位，否则 Composer 可能根本看不到它 - 末尾加
{"type": "composer", "url": "https://packagist.org/", "packagist": true}是为了兜底元数据（防止所有镜像都 404），但 ZIP 下载仍走你排第一的镜像 URL
真容灾必须靠外部脚本探测 + 切换 + 清缓存
生产环境可用的“主备切换”，本质是三步原子操作，缺一不可：
- 用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json探活，只认200 - 根据探测结果，执行
composer config --global repo.packagist composer https://xxx.com/composer/动态覆盖生效源（注意键名是repo.packagist，不是repos.packagist） - 立刻执行
composer clear-cache，否则旧packages.json缓存仍在，Composer 仍会尝试已失效的源地址
容易被忽略的关键点：
-
composer config不加--global默认改当前项目composer.json，而项目级repositories会完全屏蔽全局配置 - CI 环境中，Docker 层缓存或复用的
~/.composer/cache可能让旧镜像请求持续发出，甚至clear-cache都不一定立即生效，需配合--no-cache或强制挂载空缓存目录 - 签名验证必须开启：
composer config --global security.signature true，否则切换镜像后跳过signature校验，存在供应链风险
真正影响构建稳定性的，从来不是“配了多少个镜像”，而是能否在源失效前完成探测、是否清掉了残留元数据、以及 composer.lock 是否完整固化了所有包哈希——这三者共同构成容灾底线，缺一个，镜像再快也没用。
