composer不支持混用源是因为其查找逻辑为线性短路式，只采用首个返回有效元数据的仓库。必须设置"packagist": false禁用默认源，私有源需置repositories首位，镜像次之，且多镜像仅在404时fallback。
Composer 不能“混用源”不是因为技术上禁止，而是它的查找逻辑根本不支持“按需分流”——它只认第一个返回有效元数据的仓库，后续全跳过。所谓“混用”，往往源于对 repositories 数组行为的误读。
为什么私有包 + 阿里云镜像一起配，结果还是装了 packagist.org 的版本？
根本原因是 packagist.org 默认隐式启用，且排在所有显式仓库之后。哪怕你把私有源写在 repositories 第一位、镜像放第二位，Composer 仍会先查 packagist.org（只要没禁用），一旦它返回同名包的元数据，就立刻锁定，根本不看你的私有源或镜像。
- 必须在
composer.json根级加"packagist": false（不是放在repositories数组里，是和require并列的字段） -
repositories数组里，私有源（type: "composer"）必须放最前，镜像放中间，{"type": "composer", "url": "https://packagist.org"}可选放最后作 fallback - 千万别同时写
https://repo.packagist.org/和镜像地址——前者会抢在镜像前发起请求，断网即失败
为什么 type: "vcs" 仓库和 type: "composer" 镜像不能共存生效？
type: "vcs" 不参与全局包匹配，只对 composer require vendor/package 中显式声明的包生效；而镜像源依赖 packages.json 索引做批量匹配。两者机制不兼容，强行并列会导致部分包查不到、部分包命中错误源。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 私有 Git 仓库想被统一管理，得搭
type: "composer"服务，并生成完整packages.json和/p/{vendor}/{package}.json - 若坚持用
type: "vcs"，就别指望它和镜像“混用”——它只响应明确require的那几个包，其余全交给其他源 -
composer show vendor/package能看到当前安装来源，但注意：它只反映结果，不反映解析过程；要看真实行为，得加-vvv观察日志中实际请求了哪些 URL
为什么多个镜像源写进 repositories 数组，第二个几乎从不触发？
Composer 对镜像的 fallback 行为极其有限：只有明确返回 HTTP 404（包不存在）时，才会查下一个源；遇到 DNS 失败、连接超时、HTTP 500，直接报错退出，根本不会继续扫描数组。
- 把最稳定、最快响应的镜像（如阿里云）放在第一位，不是“优先级偏好”，而是唯一能被实际使用的源
- 多个镜像并列 ≠ 高可用，反而增加不可控延迟和失败概率
- 想模拟健康检查 fallback，得靠外部脚本预判：比如用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json检测返回是否为200，再动态生成composer.json
真正容易被忽略的是：你写的每一行 repositories 都在参与一个「线性、短路、不可回溯」的查找过程。顺序、开关、类型三者缺一不可——少设一个 "packagist": false，前面所有配置都白搭；写错一个 type，整个源就静默失效；把 vcs 和 composer 源混在一起，等于让两个不同协议的系统强行对话。
