Composer按repositories数组从上到下顺序查找包，首个匹配的包即被采用；私有仓库须置数组最前才能覆盖同名官方包，镜像仅代理packagist.org且不支持dev分支。
Composer 不按你写的顺序安装包，但会按 repositories 数组顺序查找包——这个“查”的顺序，决定了哪个包最终被装进去。
repositories 数组顺序决定包来源优先级
很多人以为改了阿里云镜像就“全局生效”，其实只是代理了 packagist.org 的索引。私有仓库、vcs 或 package 类型的仓库，完全不受镜像影响，只看你 repositories 里怎么排。
- 数组越靠前的仓库，匹配到同名包时越优先被选用——哪怕它版本更旧
- 如果你把私有 fork 放在数组末尾，而
monolog/monolog在阿里云镜像里也有，Composer 就直接装官方版，跳过你的私有仓库 -
type: "vcs"必须用 Git URL（如https://git.example.com/my/monolog），带.git后缀在某些 Composer 版本会失败 -
type: "package"必须手动写全version和dist字段，否则composer install会静默跳过
composer config repo.packagist false 的真实作用
这个命令不是“切换镜像”，而是彻底关掉默认的 packagist.org 索引。关掉后，所有依赖都必须显式出现在 repositories 列表中，包括你用的镜像地址。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 常见错误：只执行
composer config repo.packagist false，却不把阿里云镜像加进repositories→require laravel/framework直接报Package not found - 这个配置对性能几乎没影响，但会让
composer show查不到未注册的包，调试时容易误判为“包不存在” - 它不提升镜像优先级，只强制你显式声明所有来源
为什么 dev 分支还是拉不到？
因为国内主流镜像（阿里云、腾讯云等）只同步 packagist.org 上已收录的 stable 版本和 tag，不抓取 dev- 前缀分支或 dev-main 这类开发分支。
- 即使你在
repositories里写了私有vcs仓库，如果该仓库没打 tag 或没在 packagist 上 publish，Composer 默认不会去 fetch dev 分支 - 要强制装 dev 分支，得在
require里显式写"monolog/monolog": "dev-main"，且确保对应仓库支持dev-解析（比如 GitHub/GitLab 的 vcs 配置正确） - 镜像本身无法解决这个问题——它不提供 dev 分支的元数据，只缓存已发布的 release 记录
真正控制“装谁”的，从来不是 require 里怎么写版本号，而是 repositories 里谁排第一、类型是否合法、元数据是否完整。顺序错一点，私有修改就永远进不了 vendor。
