composer不支持自动fallback，仅按repositories数组顺序查找首个声明该包的源，私有源未声明则直接报错，不会尝试后续源。
私有包拉取失败时 Composer 为什么不会自动切源
Composer 默认不支持“自动 fallback 到备用源”——它只会尝试 repositories 中定义的第一个匹配源，匹配失败就报错，比如 Could not find package xxx at version yyy。这不是网络超时问题，而是 Composer 的包发现（package resolution）机制决定的：它先查所有源的 composer.json 元数据，再择一下载；如果私有源里没声明该包（或版本），就不会去其他源查。
用 composer.json 的 repositories 顺序 + 类型控制 fallback 行为
虽然不能“自动切换”，但可以通过调整 repositories 的排列和类型，让 Composer 在私有包不存在时，自然退到公共源（如 packagist.org）。关键点是：
- 把私有源放在
repositories数组**最前面**，且类型设为vcs或package（仅用于明确知道存在的包） - 把 packagist.org 显式声明为最后一个源，并设置
"packagist.org": false关闭默认隐式源，再手动加回，确保可控 - 避免对私有包使用
type: "composer"指向一个只含部分包的私有仓库 —— 如果该仓库的packages/列表里没有目标包，Composer 就直接放弃，连后续源都不看了
示例片段：
{
"repositories": [
{
"type": "vcs",
"url": "https://git.example.com/my/private-package.git"
},
{
"packagist.org": false
},
{
"type": "composer",
"url": "https://packagist.org"
}
]
}
auth.json 里写多个私有源凭据，但不等于自动 fallback
很多人以为在 auth.json 里配了多个 Git 域的 token，Composer 就会挨个试——其实不会。认证信息只是用来访问对应源，跟“选哪个源来解析包”是两件事。即使你写了：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
{
"http-basic": {
"git.example.com": { "username": "...", "password": "..." },
"git.internal.company": { "username": "...", "password": "..." }
}
}
Composer 仍只按 composer.json 里 repositories 的顺序找包，不会因为第一个私有源 404 就换第二个私有源重试。真正起作用的是源的 url 和 type 配置，不是凭据数量。
需要真·自动 fallback？得靠脚本或自定义插件
如果你的场景是“同一包名可能存在于多个私有 Git 仓库（不同团队维护），且无法预知在哪一个”，那原生 Composer 确实做不到透明 fallback。可行路径只有两个：
- 写个 shell 脚本：先
composer require --no-update xxx，捕获错误；再用sed或jq动态替换composer.json里的repositories[0].url，重试composer update - 用
composer-plugin在PreFileDownloadEvent钩子中拦截 404，动态插入备用源 URL（需注意事件触发时机和 cache 干扰）
这类方案复杂度陡增，多数团队最后都回归到“统一私有包注册中心”（比如用 Satis 或 Private Packagist），把所有私有包元数据聚合到一个可配置的 type: composer 源下——这才是 Composer 设计预期的协作方式。
