推荐通过Fork维护版本、使用patch工具或继承封装来避免Composer更新覆盖修改。首先Fork原包并提交自定义更改，然后在composer.json中指定仓库地址；或生成patch文件并借助cweagans/composer-patches插件自动应用；更优方案是通过继承或装饰器模式扩展功能，确保可维护性与升级兼容性。
直接修改 Composer 的 vendor 目录下的文件不是一个推荐的做法，因为这些文件在执行 composer install 或 composer update 时很可能会被覆盖。如果你确实做了修改并希望保留它们，可以考虑以下几种更合理的方式来避免被覆盖。
使用 Fork 并维护自己的版本
这是最正规、长期推荐的方式：
• 找到你修改的第三方包的源仓库（通常是 GitHub）• Fork 这个仓库到你自己的账号下
• 将你的修改提交到 Fork 后的仓库中
• 在项目的
composer.json 中指定使用你的 Fork：
"repositories": [
{
"type": "vcs",
"url": "https://github.com/your-username/package-name"
}
],
"require": {
"vendor/package": "dev-main"
}
这样 Composer 会从你的仓库拉取代码，不会覆盖你的改动。
使用 patch 工具自动打补丁
你可以将你的修改保存为一个 patch 文件，在每次 Composer 安装后自动应用：
• 使用diff 命令生成 patch 文件：
diff -u vendor/original/file.php modified/file.php > my-fix.patch• 安装 cweagans/composer-patches 插件：
composer require cweagans/composer-patches• 在
composer.json 中添加补丁配置：
"extra": {
"patches": {
"vendor/package": {
"Description of your patch": "path/to/my-fix.patch"
}
}
}
每次运行 composer install 时，补丁会自动应用。
替代方案：封装或继承
大多数情况下，你可以通过继承类、重写方法或使用装饰器模式来实现定制功能，而无需修改 vendor 文件。
• 创建一个新类继承原 vendor 类• 只覆盖你需要修改的方法
• 在项目中使用你的类代替原类
这种方式更安全，也更容易维护和升级依赖。
基本上就这些。不要指望手动改 vendor 能持久，要么用 fork，要么用 patch，要么重构设计绕开修改需求。这才是长久之计。
