Composer通过配置repositories指定fork源，并用分支别名或自定义版本控制依赖，建议统一fork来源、打清晰标签并定期提交PR以避免冲突。
当一个开源包被多个团队 fork 后，Composer 可以通过配置仓库（repositories）和版本约束来灵活处理这种依赖冲突问题。关键在于明确指定使用哪个 fork、如何命名分支或版本，以及避免依赖混乱。
配置自定义仓库
Composer 允许你在 composer.json 中添加额外的 VCS（如 Git）仓库，指向某个 fork 的地址：
- 在项目的根 composer.json 中添加 repositories 字段
- 指定 fork 的 Git 地址，类型为
vcs - 确保该 fork 的 composer.json 包含正确的包名和版本信息
例如：
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/team-a/forked-package"
},
{
"type": "vcs",
"url": "https://github.com/team-b/forked-package"
}
]
}
使用分支别名精准控制来源
多个 fork 往往基于原包的某个分支开发。你可以通过分支别名（branch-alias）或自定义版本标签来区分：
- 在 fork 的 composer.json 中设置
"extra": {"branch-alias"} - 引用时使用
dev-feature-branch as x.y.z格式伪装成稳定版本 - 直接使用
dev-{branch-name}指定特定分支
示例：
"require": {
"vendor/package": "dev-fix-critical-issue as 1.2.0"
}
这表示使用某个 fork 中名为 fix-critical-issue 的分支，并将其视为 1.2.0 版本。
避免依赖冲突的建议
多个 fork 容易导致同一包被不同源引入，引发冲突或加载错误：
- 统一团队内部使用的 fork 来源，避免混用
- 尽量给 fork 打上清晰的版本标签，比如
1.0.0-team-a-patch - 定期尝试向原始项目提交 PR，减少长期维护 fork 的成本
- 使用
composer show -a vendor/package查看可用版本和来源
基本上就这些。Composer 不会自动判断哪个 fork 更“正确”，必须由你明确声明依赖来源和版本策略。只要管理好仓库配置和版本别名，多 fork 场景也能稳定运行。
