Composer不支持多镜像自动fallback，需靠配置策略+外部兜底实现高可用；repositories按序匹配且仅用首个有效源；全局镜像配置为覆盖式单URL；真实容灾需异构源组合与代理层等手动设计。
Composer 本身不支持多镜像自动 fallback，所谓“高可用”必须靠配置策略 + 外部兜底来实现，不是加几行 JSON 就能自动切换。
composer.json 中的 repositories 不是故障转移列表
很多人误以为在 repositories 里写多个 composer 类型源就能自动轮询或 fallback，其实不是：
- Composer 按顺序查找包，**找到第一个匹配的就停**，不会继续往后试
-
"canonical": true的仓库优先级最高，设为false反而可能引发版本混乱（比如低版本包被意外选中） - 如果主源返回 404 或超时，Composer 不会自动跳到下一个源重试，而是直接报错
- 真实生效的只有第一个能连通且含目标包的源 —— 这本质是“多源发现”，不是“高可用容灾”
composer config -g repo.packagist.org 只接受单 URL
全局镜像配置是覆盖式写入，不是追加：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer config -g repo.packagist.org https://mirrors.aliyun.com/composer/✅ 有效 -
composer config -g repo.packagist.org https://mirrors.aliyun.com/composer/ https://packagist.phpcomposer.com❌ 第二个参数被忽略，命令还可能报Too many arguments - 这个配置项只影响 packagist.org 的镜像替换，对私有源、
repositories列表里的其他源完全无感 - CI 环境中若未显式设置，会退回到默认的
https://packagist.org，一旦它抖动，构建就卡住
真正可行的高可用组合策略
靠 Composer 自身机制做不到自动容灾，但可以组合以下手段降低单点风险：
- 用
--prefer-dist+--no-interaction减少对源站元数据的实时依赖，优先走已缓存的 dist 包 - 在 CI 脚本里加 shell 重试逻辑，例如：
for mirror in "https://mirrors.aliyun.com/composer/" "https://packagist.laravel-china.org"; do composer config -g repo.packagist.org "$mirror" && break || sleep 2 done
- 把
~/.composer/cache挂载进 CI 容器，复用历史下载结果，避免每次重拉 - 私有项目务必提交
composer.lock，它能绕过大部分源查询，直接按锁定版本安装 - 关键服务可部署轻量代理层（如 Caddy + reverse_proxy + health_check），把多个镜像源聚合成一个虚拟地址
最常被忽略的一点：镜像高可用 ≠ 源高可用。即使你配了三个镜像，只要它们都同步自同一个上游（比如都镜像 packagist.org），上游一挂，全挂。真正的冗余得来自异构源 —— 比如一个用阿里云镜像，一个用企业内网 Satis 仓库，再加一个 GitHub Packages 作为冷备。这需要你在 repositories 里手动分层设计，而不是指望 Composer 自己聪明起来。
