行，但改完会被覆盖；应使用path仓库或package仓库方案替代直接修改vendor。
直接改 vendor 里的代码行不行？
行，但改完下次 composer install 或 composer update 就会被覆盖——Composer 默认把 vendor 当作只读缓存，不跟踪你的手动修改。
常见错误现象：git status 在 vendor/xxx 下完全没反应；改完功能正常，一跑 composer update 就退回原版；CI 构建失败，因为别人机器上没你那几行 patch。
- 别在
vendor里直接git commit——它通常不是完整 Git 仓库（尤其 Packagist 包） - 别依赖“我本地改了就行”——协作、部署、CI 全会翻车
- 真正能落地的方式只有两种：用
path仓库或repositories覆盖 +require切换版本
用 path 类型 repository 临时替换包
这是最轻量、最可控的本地化方案：把想改的包复制到项目外目录，再让 Composer 认它为本地路径源。Composer 会软链接过去，改源码立刻生效，且不会被更新覆盖。
使用场景：调试第三方包逻辑、快速验证补丁、还没想好要不要提 PR 的临时修改。
- 把包拷到项目同级目录，比如
../my-laravel-validation-fix - 在项目
composer.json的repositories字段加一段：
{
"repositories": [
{
"type": "path",
"url": "../my-laravel-validation-fix"
}
]
}
- 然后改
require行，把版本号换成"dev-main as 3.2.1"（假设原包是3.2.1，你本地分支叫main） - 运行
composer update vendor/package-name——它会删掉vendor里的旧包，换成指向你本地目录的 symlink
注意：path 模式下，composer install 会跳过该包的网络请求，所以 CI 需要同步提供这个路径（或改回 packagist 源），否则会报 Package not found。
repositories + require 版本锁定绕过 Fork
如果你只是想打个临时 patch，又不想维护一个独立 Git 仓库，可以用 Composer 的 package 类型仓库，把修改后的代码打包成一个“假包”，骗 Composer 认它是原包的新版本。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
参数差异：package 仓库必须显式声明 dist（zip/tar 包地址）或 source（Git 信息），且 version 必须和 require 中一致，否则匹配失败。
- 把你改好的代码打个 zip，上传到私有 HTTP 地址（如内网 NAS 或 GitHub Gist raw）
- 在
repositories中写：
{
"type": "package",
"package": {
"name": "vendor/package-name",
"version": "3.2.1-patch1",
"dist": {
"url": "https://internal.example.com/patches/vendor-package-3.2.1-patch1.zip",
"type": "zip"
}
}
}
- 然后把
require改成"vendor/package-name": "3.2.1-patch1" - 运行
composer update即可拉取你指定的 zip
性能影响：每次 install 都要下载 zip，比 path 慢；兼容性上，所有 Composer 版本都支持，但需要确保 zip 内结构符合 PSR-4 自动加载规则（composer.json 不能丢）。
为什么不用 composer fork 或 patch 插件？
因为官方没有 composer fork 命令；而 composer-patches 插件虽然流行，但它只适用于“固定 patch 文件”，一旦原包升级导致 hunk 失败，你就得手动调 offset——这在频繁迭代的包里几乎不可维护。
容易踩的坑：
-
composer-patches的 patch 是基于原始包源码生成的，如果原包用了autoload-dev或特殊脚本，patch 后可能 autoload 错乱 - 它不解决“边改边测”的实时性问题——改一行要重生成 patch、重 apply、再
composer dump-autoload - 很多团队禁用插件（安全策略），CI 环境默认不装
composer-patches
真要长期维护修改，还是得 Fork + 提 PR；但就“临时改两天验证想法”这件事，path 方案已经足够干净——只要记得改完删掉 repositories 和 require 的别名，不然下次 update 还会去找你本地目录。
