Composer镜像优先级由repositories数组顺序决定，首个返回有效元数据的源即被采用；常见失效因项目配置覆盖全局或未禁用packagist.org导致兜底。
Composer 没有“镜像优先级”这个配置项，所谓优先级，就是 repositories 数组的书写顺序——从上到下线性扫描，第一个返回有效包元数据（不是超时、500 或 404）的源就锁定使用，后面的全跳过。
为什么改了 repositories 顺序却没走镜像
常见失效原因就两个：项目级配置覆盖全局，或没禁用 packagist.org 导致兜底。
- 检查项目根目录
composer.json是否也定义了repositories：有则优先生效，~/.composer/config.json完全被忽略 - 确认是否显式写了
"packagist.org": false：没写的话，哪怕阿里云镜像排第一，只要它对某个包返回 404，Composer 就立刻 fallback 到packagist.org - 运行
composer config repositories查看当前实际生效的源列表和顺序，别靠猜
composer config -g 不能配多个镜像
全局配置里的 repo.packagist 是单值字段，反复执行 composer config -g repo.packagist https://xxx 只会覆盖，不会追加。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 想多源共存，必须手动编辑
~/.composer/config.json或项目composer.json，用repositories数组显式声明 - 数组里不能混写
https://repo.packagist.org/和镜像 URL：前者会抢在镜像前触发网络请求，失败即中断 - 所有自定义源必须带
"type": "composer"和有效"url"，否则composer update直接报错Invalid repository type
多个镜像并存时，404 和超时行为完全不同
Composer 对错误码的反应不是统一的：遇到 404 会立即跳到下一个源；但 DNS 失败、连接超时（默认 30 秒）、HTTP 500 等，会导致命令卡住甚至失败，根本不会查第二个源。
- 把响应最快、稳定性最高的镜像放在第一位（比如阿里云通常比小众镜像更可靠）
- 避免把需要认证的私有源和公开镜像混在同一数组——一旦私有源因
auth.json缺失而卡在 401，整个流程就中断 - 生产环境建议只配一个主力镜像 +
"packagist.org": false，而不是堆砌多个“以防万一”。多源不等于高可用，反而增加不可控延迟
真正容易被忽略的是同步延迟和元数据兜底
镜像源的可用性 ≠ 同步及时性。新包发布后几分钟内查不到，不是 Composer 配置问题，而是镜像服务本身还没拉取完成。
更隐蔽的问题是：国内镜像只同步包 ZIP 和部分索引，不托管完整的 packages.json 快照。若根索引未及时更新，Composer 请求 /packages.json 就会漏掉新包。
- 解决办法是在
repositories数组末尾加一个"packagist": true条目（注意不是"packagist.org"），它会触发 Composer 回退到官方源查元数据，但 ZIP 包仍从你配的第一个镜像下载 - 别写
"packagist": {"type": "composer", "url": "https://packagist.org"}——这样会强制走官方源下 ZIP，失去镜像加速意义
