修改 vendor 中 composer.json 无效，应通过 VCS 仓库替换、path 本地覆盖或 composer-patches 插件三种方式修复依赖包问题：VCS 适合共享修复，path 适合快速验证，patch plugin 适合长期维护多补丁。
直接修改 vendor 里的 composer.json 不起作用，因为 Composer 在安装或更新时只读取包源（如 packagist 或 Git 仓库）的 composer.json，不会重新解析已下载包目录下的文件。要临时修复一个有错误的依赖包（比如字段拼写错误、PHP 版本约束写错、缺少 autoload 配置等），核心思路是：让 Composer 在安装时使用你修正后的版本，而不是原始有问题的发布版。
用 VCS repository + 分支/Tag 替换原包
这是最常用且干净的方式：把该包 fork 到你的 GitHub/GitLab，修复它的 composer.json，推送到你的远程仓库，然后在项目根目录的 composer.json 中声明自定义仓库并强制指向你的修复分支。
- fork 原包仓库（例如
vendor/package→ 你的yourname/package） - 克隆你的 fork，在本地 checkout 新分支（如
fix/composer-json），修改composer.json并提交推送 - 在你自己的项目中，编辑
composer.json，添加：
"repositories": [
{
"type": "vcs",
"url": "https://github.com/yourname/package"
}
],
"require": {
"vendor/package": "dev-fix/composer-json as 1.2.3"
}
注意：as 1.2.3 是关键——它把你的开发分支“伪装”成原包的某个稳定版本号（比如原 packagist 上 latest 是 1.2.3），这样不会破坏其他依赖的版本约束。
用 path repository 本地覆盖（适合快速验证）
如果你只是想立刻测试修复是否有效，不想 push 代码，可以用 path 类型仓库把本地已修复的包目录接入 Composer。
- 把原包源码（含已修好的
composer.json）放在项目同级目录，比如../fixed-package - 在项目
composer.json中写：
"repositories": [
{
"type": "path",
"url": "../fixed-package"
}
],
"require": {
"vendor/package": "*"
}
运行 composer update vendor/package，Composer 就会软链接（或复制）你本地的修复版进来。适合调试，但不可用于部署或协作。
用 patch plugin（长期维护多个小修复时推荐）
如果同一个包你反复要打多个补丁（比如兼容 PHP 8.3、修复 autoload、调整 require-dev），可以搭配 cweagans/composer-patches 插件，把修复逻辑变成可复现的 patch 文件。
- 先
composer require cweagans/composer-patches - 创建
patches/fix-composer-json.patch，内容为对原始composer.json的 git diff - 在项目
composer.json的extra中配置：
"extra": {
"patches": {
"vendor/package": {
"Fix broken composer.json": "patches/fix-composer-json.patch"
}
}
}
这样每次 install/update 都自动打补丁，不污染源码，也方便 PR 回上游。
基本上就这些。选哪种方式取决于你是否要共享修复、是否需要重复使用、以及有没有权限改原仓库。VCS 替换最通用，path 最快，patch plugin 最可持续。
