首先确认上游已包含所需更改，查看原始仓库提交历史或发布日志，核对 fork 中的 commit 是否已合并；接着修改 composer.json，将依赖从 fork 切换至原始包并指定包含修复的最低版本，如 “vendor/original-package”: “^1.3″；随后移除 repositories 中的 fork 配置；运行 composer update 验证安装版本及功能正常性；最后建议停止维护 fork，持续关注原项目更新，推动代码合入上游以降低维护成本。整个过程确保功能一致且依赖源干净切换。
当一个 Composer 包最初依赖于某个开源库的 fork 版本（比如你或团队修复了原项目的问题并使用了自己的 fork），而这个 fork 的改动后来被合并回原项目的主干（即上游主仓库）时，你需要平滑地将依赖从 fork 切换回原始包。以下是处理这一过程的实用方法：
1. 确认上游已包含所需更改
在切换前，先确认原始包的新版本（如新发布的 tag 或特定 commit）已经包含了你 fork 中的关键修复或功能。
- 查看原始仓库的提交历史或发布日志（CHANGELOG）
- 核对你的 fork 中的 commit 是否出现在主干中（可通过 SHA 或 PR 编号比对）
- 建议测试原始包的 dev-main 或新版本是否能正常工作
2. 修改 composer.json 依赖项
将 require 中指向 fork 的条目改回原始包，并指定包含修复的最低稳定版本或分支。
例如，原来是：
“vendor/package”: “dev-feature-branch as 1.2.3”
或指向 gitHub fork：
“your-vendor/package”: “^1.2”
改为：
“vendor/original-package”: “^1.3” // 假设 v1.3 包含了你的改动
3. 移除 repositories 中的 fork 配置（如有）
如果你在 composer.json 中通过 repositories 添加了 fork 地址，现在可以移除它：
// 删除类似如下配置： { “type”: “git“, “url”: “https://github.com/yourname/package-fork” }
Composer 将自动从 Packagist 获取原始包。
4. 更新依赖并验证
运行以下命令更新依赖：
composer update vendor/original-package
检查：
- 安装的版本是否正确
- 功能是否仍正常（特别是你之前修复的部分）
- 是否有冲突或额外提示
5. 后续维护建议
一旦切回原始包，应：
- 取消维护自己的 fork（或保留归档状态）
- 关注原始项目的更新节奏，避免再次需要 fork
- 考虑向原项目贡献代码，减少长期维护成本
基本上就这些。关键是确保功能一致性，然后干净地切换来源。Composer 本身不会“记住”你曾用过 fork，只要包名和版本匹配，它只关心最终满足依赖的源。