在不修改 vendor 目录前提下测试依赖补丁，核心是让 Composer 临时指向本地代码：可用 path 仓库软链接、composer-patches 插件打补丁，或 vcs 方式引用 GitHub fork 分支；测试后需清理配置并恢复原始版本。
在不修改 vendor 目录的前提下测试依赖包的补丁，核心思路是让 Composer 临时“指向”你本地修改后的代码，而不是从远程仓库或已安装的 vendor 中加载。这既保证了测试可行性，又避免污染生产依赖环境。
使用 path 仓库类型临时替换依赖
这是最常用且安全的方式。你无需动 vendor，只需告诉 Composer：这个包现在从我本地某个路径读取。
- 在项目根目录的
composer.json中添加自定义仓库（放在repositories数组里）：
"repositories": [
{
"type": "path",
"url": "../my-fixed-package"
}
]
- 确保
../my-fixed-package是你 fork 并打完补丁的包目录，且其composer.json中的name字段与原包完全一致（如"monolog/monolog"）； - 将该包的版本号设为开发版（如
"dev-main"或带@dev后缀），然后运行：composer require monolog/monolog:dev-main@dev --no-update，再执行composer update monolog/monolog； - Composer 会软链接（symlink）该路径到
vendor/monolog/monolog，所有调用都走你的补丁代码，但vendor本身仍是干净的（实际是符号链接）。
利用 composer patch plugin（适用于小补丁）
如果你只是加几个 .patch 文件，不想维护整个包副本，可用 cweagans/composer-patches 插件。
- 先安装插件：
composer require cweagans/composer-patches --dev； - 把补丁文件（如
fix-null-pointer.patch）放到项目内（如patches/目录）； - 在
composer.json的extra.patches中声明：
"extra": {
"patches": {
"vendor/package-name": {
"Fix crash on empty input": "patches/fix-null-pointer.patch"
}
}
}
- 运行
composer install或update，插件会在安装依赖后自动打补丁——整个过程不触碰vendor源码手动编辑，且补丁可提交、可复现。
用 GitHub fork + dev branch 替换（适合协作验证）
当你需要团队成员或 CI 也能复现时，把补丁推到自己的 GitHub fork 分支更可靠。
- fork 原包仓库，切分支（如
fix/login-timeout），提交补丁并 push； - 在项目
composer.json的repositories中添加 type: vcs：
"repositories": [
{
"type": "vcs",
"url": "https://github.com/yourname/package-name.git"
}
]
- 然后指定版本：
composer require vendor/package-name:dev-fix/login-timeout#commit-hash； - Composer 会克隆该 fork 分支到 vendor，并只对该包生效，不影响其他依赖。
验证与清理建议
无论用哪种方式，测试完成后记得还原，避免误提交脏配置。
- 检查是否真在用补丁代码：查看
vendor/package-name是否为 symlink（path 方式）或确认 commit hash（vcs 方式）； - 运行
composer show vendor/package-name查看当前加载的源和版本； - 测试通过后，若要恢复原始版本，删掉
repositories配置 +composer update vendor/package-name即可； - 补丁合入上游后，及时移除临时配置，改用稳定版本。
