Composer不支持镜像权重调度或自动选最快机制，仅按repositories数组顺序线性查找首个返回200+有效JSON的源并锁定使用，404才触发下一源，超时或500等错误直接报错退出；全局config -g repo.packagist为单值字段，后设覆盖前设，多镜像容灾须依赖外部脚本探测+动态切换。
Composer 不支持镜像权重调度，也不存在“自动选最快”或“按响应时间动态切换”的机制。所谓多镜像权重配置，是常见误解——它根本不会测速、不健康检查、不重试、不轮询。
composer config -g repo.packagist 只能设一个 URL
这个配置项是单值字段，底层对应 JSON 中的 "repo.packagist" 字符串。执行两次：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ composer config -g repo.packagist composer https://mirrors.tencent.com/composer/
第二条会直接覆盖第一条，不是叠加，也不报错。所有“用空格拼多个地址”或“反复 config 就能生效”的做法都无效。
-
repo.packagist必须带-g，否则只改当前项目，换目录就失效 - 键名必须是
repo.packagist（单数、小写、无点），写成repos.packagist.org或packagist.org都静默失败 - URL 必须以
/结尾，否则拼出的路径如/composerpackages.json会 404
repositories 数组不是 fallback 机制
你在 composer.json 里写多个 {"type": "composer", "url": "..."} ，Composer 只做一件事：按顺序请求每个源的 packages.json，合并成一张元数据索引表。安装时，从第一个声明了该包完整版本信息的源拉 ZIP 包，其余源完全不参与下载阶段。
- 只有某个包在第一个源返回明确的
404（不是超时、502、DNS failed），才会查第二个源 - 遇到超时或 500，Composer 默认等待 30 秒后直接报错退出，根本不触发下一个
- 如果第一个镜像返回了
200+ 合法 JSON（哪怕不含你要的包），后续所有源全跳过 -
"packagist.org": false必须作为独立对象写在repositories数组末尾，漏掉引号、布尔值或位置错误，官方源仍会隐式兜底
真·容灾必须靠外部脚本控制
想实现“阿里云挂了切腾讯云”，不能依赖 Composer 自身逻辑，唯一可靠路径是三步外部控制流：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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 -g repo.packagist切换目标地址 - 切换后必须执行
composer clear-cache，否则旧镜像的元数据可能残留导致 404
别忘了删掉 vendor/ 和 composer.lock 再运行 composer install，否则 lock 文件里存的仍是旧源哈希，换镜像也无效。
项目级配置优先于全局，且更可控
全局配置容易被 CI 用户权限、项目内 repositories 声明覆盖，而项目级配置可 Git 跟踪、团队统一。正确写法是进项目根目录执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动在 composer.json 顶层写入 "repositories" 字段，key 固定为 "packagist"，不会覆盖已有私有源——前提是原来 repositories 是对象结构（不是数组）。
- 如果项目已存在
"repositories": []数组，别手动覆盖，用命令追加，否则可能误删私有包源 - 多个镜像并列写进
repositories数组基本没意义：只要第一个镜像服务在线，哪怕响应慢，Composer 也会等满 30 秒才失败，第二个镜像永远不会被访问 - 自建镜像必须启用 providers 索引（如 Satis 的
providers选项），否则 Composer 不知道你支持哪些包
最常被忽略的复杂点：镜像只同步元数据索引和 ZIP 包，不托管 packages.json 的完整快照。新包发布后，镜像同步有延迟；此时第一个镜像返回 404，第二个镜像大概率也没同步——所谓“主备”在现实中往往只是心理安慰。
