composer仓库优先级本质是“匹配即停”的线性查找，仅当显式配置"packagist": false禁用默认源后，repositories数组顺序才真正生效；否则packagist.org始终兜底，顺序无效。
Composer 的 repositories 优先级不是“排序”，而是「匹配即停」的线性查找逻辑——顺序只在禁用默认源后才真正起作用，否则 packagist.org 总是兜底。
为什么改了 repositories 顺序却没生效？
因为默认情况下 Composer 并不按你写的顺序查包：只要没显式禁用 packagist.org，它就会被自动移到最后作为 fallback 源。哪怕你把它写在 repositories 数组第一行，也改变不了这个行为。
- 现象：
composer require myorg/utils仍从 packagist.org 安装，而不是你配置的私有 GitLab 仓库 - 原因：私有仓库没在
packages字段声明该包，或没设"type": "composer"，导致 Composer 认为“不支持”，直接跳过 - 关键点：
repositories数组中每个仓库必须明确“我能提供哪些包”，否则顺序再靠前也没用 - 验证方法：运行
composer show -p myorg/utils，看输出里source指向哪个 URL
如何让私有仓库真正优先生效？
必须同时满足三个条件：顺序置顶 + 类型正确 + 显式覆盖包范围。缺一不可。
- 把私有仓库放在
repositories数组最前面（索引 0） - 确保
type是"composer"（不是"vcs"或"package"），且url指向一个可访问的packages.json文件 - 在该私有仓库的
packages.json中，必须包含完整包名（如"myorg/utils"），大小写、斜杠方向与require中完全一致 - 如果只想让这个仓库服务特定包，可用
"package"类型替代：{"type": "package", "package": {"name": "myorg/utils", "version": "dev-main", "dist": {...}}}
packagist.org 要不要禁用？怎么禁？
禁用与否取决于你的策略：想彻底隔离外部源就关，想保留 fallback 就手动声明为普通仓库。
- 彻底禁用：
"packagist": false—— 此时所有包都必须由你定义的仓库提供，repositories顺序才严格生效 - 保留 fallback 但控制顺序：
"packagist.org": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}—— 把镜像显式写成一个普通仓库，并放在私有仓之后、数组末尾之前 - 绝对不要写
"packagist": true或留空，这是默认行为，会强制降权 - 别用
composer config -g repos.packagist.url全局改，它会覆盖项目级配置，导致私有仓库失效
常见踩坑：数组写法和 auth.json 分离
repositories 必须是索引数组，不能是关联数组；认证信息必须抽离到 auth.json，否则私有仓库 401。
- 错误写法：
"repositories": {"private": {"type": "composer", "url": "..."}}→ 只有最后一个键生效 - 正确写法：
"repositories": [{"type": "composer", "url": "..."}, {"type": "composer", "url": "..."}] - 私有仓库若需 token 或 basic auth，必须写进
auth.json（同级目录），格式为：{"http-basic": {"your.repo.domain": {"username": "...", "password": "..."}}} - 改完
composer.json后务必运行composer update --lock，否则composer.lock里仍存旧源信息
最易忽略的一点：私有仓库返回的 packages.json 必须能被 Composer 解析出有效版本列表——如果里面只有 "packages": {} 或版本字段缺失，就算顺序再靠前，也会被跳过。
