是的，repositories数组顺序决定优先级；Composer从上到下查找，命中即止，同名包后序仓库被忽略，packagist.org始终排在显式仓库之后。
composer.json 里 repository 数组顺序真的决定优先级
是的，composer.json 中 repositories 数组的书写顺序，就是 Composer 解析包时的实际查找顺序。它从上到下逐个仓库查，找到第一个匹配的包就停止，不会继续往下找——哪怕后面仓库里的版本更新、更符合约束。
常见错误现象：composer require vendor/package 安装了旧版，或者提示找不到包，但你确认私有仓库 A 里有 v2.0.0，而仓库 B（排在前面）只提供了 v1.5.0；又或者你刚推送了一个新 tag 到私有 GitLab 仓库，composer update 却没拉下来，因为排在它前面的另一个私有仓库返回了“包不存在”或“无匹配版本”，Composer 就直接报错了，根本没走到你那个仓库。
- 必须把**最可信、最新、最优先使用**的私有仓库放在
repositories数组最顶部 - 如果多个仓库提供同一个
vendor/package，只有第一个生效，后面同名包会被完全忽略 -
packagist.org默认是隐式兜底仓库（除非显式禁用），但它永远排在所有显式声明的repositories之后
如何避免“同名包被错误仓库劫持”
当两个私有仓库都声明了 myorg/utils，但一个走 Git 镜像、一个走 Satis 构建的静态 repo，很容易因顺序错乱导致依赖行为不一致。关键不是“怎么让 Composer 合并”，而是“怎么让它别误选”。
- 统一命名空间：不同团队/项目尽量用不同 vendor 前缀，比如
team-a/utils和team-b/utils，从根本上规避冲突 - 禁用不需要的仓库：用
"packagist": false关掉默认源后，再只声明你真正需要的那 1–2 个私有仓库，减少干扰面 - 用
composer show vendor/package --all查看 Composer 实际解析到了哪个仓库的哪个版本，确认是否如预期 - 不要在
repositories里混写vcs和composer类型仓库来“凑功能”，类型差异会导致元数据解析逻辑不同，优先级判断可能隐含陷阱
type=package 的仓库为什么容易踩坑
"type": "package" 是手动声明单个包的元信息，常用于封装未托管在 VCS 的闭源组件。但它没有自动发现能力，且优先级规则和其他类型一致——只要排在前面，就会拦截所有对该包的请求，哪怕你只是想 require 一个普通版本号。
- 它会完全覆盖同名包在其他仓库中的任何版本，包括
dev-main或dev-feature/x这类开发分支 - 如果你写了
"version": "1.2.3"，Composer 就只认这个字符串，不会去 Git 仓库里 fetch tag，也不会响应composer update --with-dependencies的联动更新 - 一旦
type=package仓库排在前面，而你又忘了同步更新它的dist地址或source提交哈希，composer install可能静默拉取旧二进制或报 404
调试仓库解析过程的实用命令
光看 composer.json 不足以确认实际行为，得让 Composer “开口说话”。
-
composer config repositories：列出当前生效的所有仓库（含隐式 packagist），注意输出顺序就是真实优先级 -
composer diagnose -v：加-v会显示每个仓库的 type、url、是否可用，还能看到是否被跳过（比如证书校验失败） -
composer update -vvv | grep -A5 "Reading composer.json"（Linux/macOS）：观察详细日志里它到底访问了哪个 URL，尤其关注 “Loading from cache” 或 “Downloading” 后面的地址 - 临时注释掉部分
repositories条目，再运行composer show vendor/package，对比输出变化，快速定位是哪个仓库在起作用
真正的复杂点不在怎么写顺序，而在多人协作时没人主动维护这个数组——今天 A 加了个测试仓库放最前，明天 B 发布正式包却忘了调序，问题就藏在 git diff 里，等上线才暴露。所以建议把它当成敏感配置，和 autoload 一样放进 CR 检查清单。
