composer镜像优先级严格按repositories数组从上到下线性匹配，首个返回200+有效json的源即被锁定使用，后续全跳过；仅404触发下一源，超时或500等错误直接报错；必须显式配置{"packagist.org": false}置于数组末尾，且私有vcs源须置顶。
repositories 数组顺序就是实际优先级
Composer 不解析“哪个镜像更快”，只按 repositories 数组从上到下线性尝试：第一个返回 HTTP 200 + 可解析 JSON 元数据的源就被锁定，后续全部跳过。这不是 fallback，是硬性短路逻辑。
- 私有 VCS 源（如 GitLab 地址）必须放在数组最前，否则同名公共包会被镜像提前截断
- 阿里云镜像（
https://mirrors.aliyun.com/composer/）建议放第二位——响应快、同步全，覆盖绝大多数公共依赖 - 腾讯云等备用镜像可放第三位，但仅当阿里云对某包明确返回
404时才触发，不是“连不上就切” - 绝对不要把
https://repo.packagist.org/和镜像 URL 同时写进数组——它会抢在镜像前发请求，失败即中断
禁用 packagist.org 必须显式且独立
没加 {"packagist.org": false}，Composer 就会隐式启用官方源作兜底，导致你配置的镜像形同虚设：哪怕阿里云排第一，只要它对新包返回 404，立刻切回官方源。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 这行必须作为独立对象写入
repositories数组末尾，不能嵌套、不能拼错键名（不是"packagist"，也不是"packagist.com"） - 不能靠全局配置替代：项目级
composer.json中定义了repositories，全局设置（~/.composer/config.json）就完全失效 - 验证是否生效：运行
composer config repositories，输出中应只出现你的镜像 URL，且明确含"packagist.org": false
多镜像共存 ≠ 自动容错，超时和 5xx 不触发切换
Composer 对错误的处理逻辑高度差异化：只有 404 会继续查下一个源；DNS 失败、连接超时（默认 30 秒）、502、500 等一律报错退出，根本不会尝试第二源。
- 阿里云镜像返回
500→ 直接报Could not fetch packages.json，腾讯云镜像完全不触发 - 镜像延迟未同步新包 → 返回
404→ 才轮到下一镜像，但后者也可能尚未同步 - 生产环境建议只配一个主力镜像 +
{"packagist.org": false}，堆砌多个源不提升可用性，反而增加不可控延迟 - 想模拟 fallback？得靠外部脚本检测可用性：
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json返回200才设为当前源
换镜像后必须清空 vendor 和 lock 文件
composer.lock 里记录的是源地址哈希，不是镜像 URL 本身。旧 lock 文件仍指向 packagist.org 的 hash，换镜像后不删它，Composer 仍会尝试从原站拉包，配置白改。
- 删掉
vendor/和composer.lock，再执行composer install - 如果用了
composer create-project初始化，尤其要注意这点——初始 lock 往往绑定官方源 - 自建镜像或私有源需提供完整索引（如
/packages.json和/p/{vendor}/{package}.json），否则 Composer 会直接报Could not find package，连下一个源都不试
