composer 本身不支持打补丁，需依赖 vaimo/composer-patches 插件实现；手动修改 vendor 代码极危险，fork 适用于重度修改或原包停滞场景。
composer patch 机制不存在，得靠插件或手动覆盖
Composer 本身不支持给已安装的第三方包打补丁（比如 git diff 文件），也没有内置的 patch 命令。你看到的“打补丁”效果，基本都来自第三方插件（如 vaimo/composer-patches）或 hack 式覆盖——后者容易在下次 composer install 时被冲掉。
用 vaimo/composer-patches 插件加补丁最稳妥
这是目前主流、稳定、且支持 Composer 2.x 的补丁方案。它把补丁文件声明在 composer.json 里，每次安装/更新都会自动应用，还能校验 SHA256 防篡改。
- 先安装插件：
composer require vaimo/composer-patches - 在
composer.json的"extra"下加 patch 配置，例如："extra": { "patches": { "monolog/monolog": { "Fix broken handler fallback": "patches/monolog-fallback-fix.patch" } } } - 补丁文件必须是
git format-patch或标准 unified diff（diff -u），且路径要相对于包根目录（不是项目根目录） - 注意：如果补丁应用失败（比如 hunk offset 偏移错），
composer install会直接报错退出，不会静默跳过
直接改 vendor 里的代码？别这么做
有人习惯打开 vendor/some/package/src/xxx.php 直接改，短期能跑通，但极危险：
-
composer update some/package或composer install --no-dev会彻底清掉修改 - CI/CD 环境下根本不可控，别人拉代码就失效
- Git 会把
vendor/当作未跟踪文件，git status永远飘红，干扰协作 - 没留痕、没复现路径，半年后自己都忘了当初改了哪行
补丁 vs Fork：什么情况该 fork 包？
当你要改的逻辑较重（比如新增接口、重构类结构）、补丁超过 3 个、或原包长期不维护时，fork 更可持续：
- 在 GitHub fork 原仓库 → 修改 → push 到你的远程分支（如
fix-redis-timeout） - 在
composer.json中用"repositories"指向你的 fork，并用"dev-fix-redis-timeout as 2.8.0"别名覆盖版本 - 注意：fork 后要定期 rebase upstream，否则很快和主干脱节；别忘了在 PR 里 @ 原作者，争取合入上游
- 如果只是临时绕过一个 bug，优先选 patch；如果改的是核心行为，fork 才是正解
补丁路径写错、hunk 偏移失效、fork 分支没设好别名——这三处出问题，90% 的“打补丁失败”就发生在这里。
