在不修改 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 即可；
• 补丁合入上游后，及时移除临时配置，改用稳定版本。