可用 repositories + replace 组合优雅接管开源包分叉版本：先在 repositories 中声明 vcs 类型的 fork 地址，确保其 composer.json 的 name 与原包一致；再用 replace 字段强制替代原包依赖；最后通过 version 和 stability 配置确保正确安装。
当你需要在项目中使用某个开源包的分叉版本（比如修复了 bug 或添加了私有功能），又不想直接改写 composer.json 中的依赖为 vcs 类型、破坏原有约束，或者想让团队 /CI 无需额外配置就能拉取你的分叉，就可以用 repositories + replace 的组合来优雅接管原包。
用 repositories 指向你的 fork 仓库
在项目的 composer.json 中，通过 repositories 声明一个类型为 vcs 的源，指向你的 GitHub/GitLab 分叉地址。Composer 会优先从此处解析包，而不是 Packagist。
例如，你想用自己维护的 monolog/monolog 分叉：
"repositories": [{ "type": "vcs", "url": "https://github.com/yourname/monolog"} ]
⚠️ 注意：这个仓库的 composer.json 中必须声明正确的 name（如 "monolog/monolog"），否则 Composer 找不到匹配项。
用 replace 确保原包被彻底替换
仅靠 repositories 有时不够——如果其他依赖仍显式要求原包（比如 "monolog/monolog": "^2.0"），而你的 fork 没有打对应 tag 或版本不兼容，Composer 可能回退到 Packagist 上的原始版本。
这时，在项目根 composer.json 的 replace 字段中明确“替代”原包：
"replace": {"monolog/monolog": "*"}
这告诉 Composer：“不管谁要 monolog/monolog，都用我当前已加载的这个（即从你 fork 里安装的）来满足，不许再去别处找”。它不下载新包，只做版本映射层面的覆盖。
配合 version 和 stability 控制实际安装行为
你的 fork 仓库里的 composer.json 需要合理设置 version 和 minimum-stability，否则可能因稳定性不匹配被跳过。
- 如果你的 fork 基于
v2.10.0修改，建议在 fork 的composer.json中设"version": "2.10.0-patch1"（或用dev-main+as别名） - 项目根
composer.json中可加"minimum-stability": "dev"和"prefer-stable": true来兼顾兼容性与稳定性 - 运行
composer update monolog/monolog后，检查输出是否显示“Loading from cache”或“Cloning……”你的 fork 地址，确认生效
避免常见陷阱
这些细节没处理好，容易导致 fork 不生效或 CI 失败：
- fork 仓库的
composer.jsonname 必须和原包完全一致 （包括大小写和斜杠），否则repositories找不到目标 - 不要在项目中同时 require 原包和 fork 包（比如既写
"monolog/monolog"又写"yourname/monolog"），会冲突 -
replace是“软替换”，不改变依赖图结构；若需彻底移除原包逻辑，应配合conflict字段阻止其被间接引入 - 私有 fork 若托管在 GitHub 私仓，需提前配置 SSH key 或 GitHub token，否则
composer install会权限失败
基本上就这些。核心就是三步：声明你的源、确保名字对得上、用 replace 锁定替代关系。不复杂但容易忽略细节。
