不能真正覆盖第三方包，必须提供替代代码：path仓库本地链接最常用安全，package仓库适合封闭环境，replace仅限包作者声明替代关系。
不能在不更改代码的前提下真正“覆盖”第三方包——所谓“依赖劫持”本质是让 Composer 加载你控制的代码，而你必须提供新代码（哪怕只改一行）。 直接修改 vendor/ 下的文件看似“没改自己项目代码”，但会被 composer install 或 composer update 立刻清掉，协作和 CI 全崩。真要生效，必须用 Composer 原生支持的替换机制，且需你主动提供替代内容。
用 path 仓库本地链接包（最常用、最安全）
适合调试、打临时补丁、验证修复逻辑，改完立刻生效，且不污染 vendor/ 的解压结构。
- 把想改的包完整复制到项目外目录，比如
../laravel-validation-patch，然后在里面改源码（哪怕只加一行var_dump()） - 在项目
composer.json的repositories字段加：{ "type": "path", "url": "../laravel-validation-patch" } -
require行改成"laravel/framework": "dev-main as 10.42.0"（假设原版本是10.42.0，你本地分支叫main） - 运行
composer update laravel/framework—— 它会删掉原来的包，换成指向你本地目录的符号链接 - ⚠️ 注意：CI 构建时该路径必须存在，否则报
Package not found；上线前务必切回正式源
用 package 类型仓库伪造一个“假包”
适合不想暴露 Git 仓库、或只能发 zip 包的封闭环境（如内网 NAS、GitHub Gist raw 链接）。
- 把你改好的代码打包成
my-fix.zip，上传到可公开访问的 HTTP 地址（如https://internal.example.com/pkg/my-fix.zip） - 在
repositories中声明：{ "type": "package", "package": { "name": "laravel/framework", "version": "10.42.0-patch1", "dist": { "url": "https://internal.example.com/pkg/my-fix.zip", "type": "zip" } } } -
require改成"laravel/framework": "10.42.0-patch1"，再跑composer update - ⚠️ 关键：
version字段必须和require中完全一致，否则匹配失败；dist.url必须能被 Composer 下载（无鉴权、无重定向）
用 replace 声明功能替代（仅限包作者）
这是唯一一种“不提供新代码也能让旧包失效”的方式，但前提是——你得发布一个新包，并在它的 composer.json 里写 replace。
- 例如你发布
acme/validation-kit，并在其composer.json中写："replace": { "laravel/framework": "^10.0" } - 然后在项目中
require这个新包，Composer 就不会再装laravel/framework - ⚠️ 它不加载你的代码，只是“删掉”原包；你仍需确保新包提供了等效功能，否则运行时报类找不到
- 普通用户无法用这个绕过依赖——它不是劫持，是正向声明替代关系
最容易被忽略的一点：所有这些方案都要求你**明确提供替代代码**。没有“零修改”的覆盖；所谓的“不改代码”，往往只是把修改藏到了别处（本地路径、zip 包、另一个包），而那个地方的代码，才是实际生效的部分。
