你有没有遇到过这样的情况：在你的php项目里，某个 composer 依赖包几乎完美，但就是有一个小小的功能不符合你的需求，或者有一个 bug 需要你立即修复，而官方版本还没来得及更新？
这时候，你可能会想：直接去
vendor/目录里改一下不就行了？
是的，你确实可以这么做。但问题是，一旦你运行
composer update或者
composer install，你的所有修改都会被无情地覆盖掉！这简直是开发者的噩梦。为了一个微小的改动去 Fork 整个仓库，然后维护自己的分支，又显得过于笨重和耗时。手动管理
.patch文件，也容易出错且难以维护。
这种困境，相信很多PHP开发者都深有体会。它不仅浪费时间，还增加了项目维护的复杂性。那么，有没有一种既能灵活修改依赖包，又能保证修改不会被覆盖，同时还易于管理和团队协作的方案呢？
答案是肯定的！今天，我要向大家隆重推荐一个 Composer 生态中的神器——
migrify/vendor-patches。这个工具完美解决了我们修改第三方依赖包的痛点，它能帮助你轻松生成并应用对
vendor目录中文件的修改，而无需直接改动原始文件或 Fork 整个仓库。
migrify/vendor-patches的核心思想是：通过比较你修改后的文件和原始文件，自动生成一个
.patch文件。然后，结合
cweagans/composer-patches这个库，在每次
composer install或
composer update时，自动将这些补丁应用到你的
vendor目录中。这样一来，你的修改就有了版本控制，再也不怕被覆盖了！
如何使用 migrify/vendor-patches
？
接下来，让我们看看如何一步步使用
migrify/vendor-patches来解决这个问题。
1. 安装必要的依赖
首先，我们需要通过 Composer 安装
migrify/vendor-patches和
cweagans/composer-patches。
migrify/vendor-patches主要用于生成补丁，通常只在开发环境中使用，所以我们可以将其作为
dev依赖安装；而
cweagans/composer-patches则是负责在
composer install时实际应用补丁的，如果你的补丁需要在生产环境生效，那么它就必须作为普通依赖安装。
composer require symplify/vendor-patches --dev # 如果需要在生产环境应用补丁，请务必安装 cweagans/composer-patches composer require cweagans/composer-patches
2. 复制你想要修改的 Vendor 文件并添加 .old
后缀
现在，假设你需要修改
vendor/nette/di/src/DI/Extensions/InjectExtension.php这个文件。第一步是复制这个文件，并在副本的末尾添加
.old后缀。注意：是复制，不是重命名！
vendor/nette/di/src/DI/Extensions/InjectExtension.php # 这是你将要修改的原始文件 vendor/nette/di/src/DI/Extensions/InjectExtension.php.old # 这是原始文件的备份
3. 修改原始文件
现在，你可以大胆地打开
vendor/nette/di/src/DI/Extensions/InjectExtension.php这个文件，进行你需要的修改了。例如，我们想要修改其中一行代码，使其使用我们自己的反射辅助类：
if (DI\Helpers::parseAnnotation($rp, 'inject') !== null) {
- if ($type = DI\Helpers::parseAnnotation($rp, 'var')) { // 原始代码
+ if ($type = \App\Reflection\Helper\StaticReflectionHelper::getPropertyType($rp)) { // 我们的修改
+ } elseif ($type = DI\Helpers::parseAnnotation($rp, 'var')) { // 兼容原始逻辑
$type = Reflection::expandClassName($type, Reflection::getPropertyDeclaringClass($rp));一个非常棒的特性是：只有没有 .old
后缀的文件会被加载和执行。这意味着你可以在生成补丁之前，先运行你的应用程序，确保你所做的修改是正确的并且没有引入新的问题。这大大降低了风险！
4. 运行 generate
命令，生成补丁！?️
当你的修改测试通过后，激动人心的时刻到了！运行
vendor-patches generate命令，它会遍历所有带有
.old后缀的文件，并为你生成对应的
.patch文件。
vendor/bin/vendor-patches generate
命令执行后，你会在项目根目录下看到一个
patches/目录，里面包含了为你生成的补丁文件，例如：
/patches/nette-di-di-extensions-injectextension.php.patch。这个补丁文件的命名是基于原始文件路径的，保证了其唯一性。
更智能的是，
migrify/vendor-patches还会自动更新你的
composer.json文件，在
extra配置项中添加
cweagans/composer-patches所需的补丁信息：
{
"extra": {
"patches": {
"nette/di": [
"patches/nette_di_di_extensions_injectextension.patch"
]
}
}
}如果你有特殊的补丁文件路径需求，也可以通过
--patches-file选项来指定：
vendor/bin/vendor-patches generate --patches-file=patches.json
5. 应用补丁
现在，万事俱备，只欠东风！你只需要运行标准的 Composer 安装命令，你的补丁就会被自动应用到
vendor目录中了！
composer install
如果补丁没有成功应用，或者你想查看更详细的日志，可以使用
--verbose选项：
composer install --verbose
小贴士： 如果你使用的是 macOS 系统，并且在应用补丁时遇到问题，可能是因为缺少
gpatch工具。你可以通过 Homebrew 安装它：
brew install gpatch
优势与实际应用效果
使用
migrify/vendor-patches带来的好处是显而易见的，它彻底改变了我们处理第三方依赖的方式：
-
优雅且非侵入式： 你的修改以补丁的形式存在，不会直接污染
vendor
目录，保持了项目的整洁性。 - 可维护性极强： 补丁文件可以像其他代码一样被版本控制（Git），方便团队成员共享和追踪修改。
-
自动化管理： 借助
cweagans/composer-patches
，补丁的安装和更新完全自动化，无需手动干预。 - 灵活且精准： 你可以只对你需要的部分进行修改，而不是被迫接受整个 Fork 带来的复杂性。
- 告别 Fork 困境： 对于小的改动，你不再需要 Fork 整个仓库，节省了大量的维护成本和时间。
-
团队协作无忧： 团队成员只需
composer install
，就能获得所有必要的补丁，确保开发环境的一致性。
总结
在现代PHP开发中，Composer 已经成为不可或缺的工具。而
migrify/vendor-patches则是 Composer 生态中一个非常实用的补充，它解决了许多开发者在处理第三方依赖时面临的痛点。通过它，我们能够以一种更加专业、高效、可维护的方式来管理对
vendor包的修改，让我们的项目更加健壮，开发流程更加顺畅。下次再遇到需要微调依赖包的情况，不妨试试这个神器，它一定会让你爱不释手！
