Composer按repositories数组从上到下的顺序查找包，命中即止；需通过调整声明顺序控制优先级，避免同名同版本包冲突，并用composer config动态管理环境仓库。
在一个项目中同时使用多个私有 Composer 仓库时，关键不在于“叠加”，而在于**声明顺序决定优先级**：Composer 会按 composer.json 中 repositories 数组的**从上到下的顺序**依次查找包，一旦在某个仓库中找到匹配的包（名称和版本都满足），就停止搜索，不会继续往后找。
仓库声明顺序 = 解析优先级
Composer 不合并多个仓库的结果，而是线性扫描。比如你配置了三个私有源：
- 公司内部核心组件仓库（
https://repo.company.com/core） - 部门级工具包仓库（
https://repo.team.com/utils） - 测试用的临时 fork 仓库（
https://repo.dev/forked-laravel）
若你想让某个 fork 包（如 laravel/framework）优先被拉取，就必须把它放在 repositories 数组的最前面：
"repositories": [
{
"type": "composer",
"url": "https://repo.dev/forked-laravel"
},
{
"type": "composer",
"url": "https://repo.company.com/core"
},
{
"type": "composer",
"url": "https://repo.team.com/utils"
}
]
避免冲突：包名必须唯一且明确
多个私有仓库里不能存在同名同版本的包（比如都提供 acme/logger v1.2.0），否则行为不可控——Composer 只取第一个命中项，但你无法保证哪台机器、哪个缓存状态会触发哪个源。建议：
- 统一约定命名空间前缀（如
company/、team/、dev/），从源头隔离包名 - 对需要覆盖的官方或第三方包，用
replace或provide明确声明替代关系 - 不要依赖“某个仓库没这个包，所以自动 fallback 到下一个”——这属于隐式逻辑，难以维护
按需启用：用 composer config 动态管理
开发、测试、上线环境可能需要不同仓库组合。可借助 Composer 的配置机制动态切换：
- 本地开发时添加临时仓库：
composer config repositories.dev composer https://repo.dev/test - 上线前禁用测试源：
composer config --unset repositories.dev - 所有配置最终合并进
composer.json的repositories，仍遵循顺序优先级
验证是否生效：用 composer show 和 -vvv
运行 composer show vendor/package 可看到当前安装的包来自哪个仓库；加 -vvv 参数执行 composer update 时，Composer 会打印每一步尝试访问的仓库 URL，清楚展示它在哪一层找到了包。
基本上就这些。重点不是堆仓库，而是理清谁先谁后、谁管谁、谁不该重叠。不复杂但容易忽略顺序细节。
