Composer如何修改vendor包依赖版本且不生成嵌套vendor目录

首先明确核心规则：所有/vendor目录下的内容都是Composer自动生成的依赖文件，直接手动修改该目录下的composer.json、或者在子包目录单独执行composer命令，都不符合规范——前者会在下次执行composer install/update时被全量覆盖，后者会生成嵌套vendor目录，破坏全局自动加载逻辑，引发类冲突、版本错乱问题。

可落地的合规方案按优先级排序：

• 方案一：上游包更新（最推荐，完全符合生态规范）
  1. 先修改mypackage/pdf包自身的composer.json，将三个依赖的版本约束调整为目标版本，验证兼容性后发布新的包版本
  2. 调整mypackage/backend包中对mypackage/pdf的版本约束，允许拉取你刚发布的、升级了依赖的新版本
  3. 回到项目根目录执行composer update mypackage/backend mypackage/pdf --with-all-dependencies，Composer会自动完成全量依赖的版本解析，所有包都会平铺安装到根目录vendor文件夹下，不会生成嵌套目录。
• 方案二：根目录配置强制版本（临时兼容方案，适合暂时无法推动上游更新的场景）
  直接在项目根目录的composer.json中做配置：
  1. 在require段显式声明三个PDF相关依赖的目标版本，和你需要的版本约束完全一致：

     "require": {
       "mypackage/backend": "^5.0",
       "tecnickcom/tcpdf": "6.4.*",
       "setasign/fpdi": "*",
       "setasign/fpdi-tcpdf": "2.*"
     }
     

  2. 如果你用的是自定义维护的mypackage/pdf分支，可以在根composer.json中添加repositories配置，指向你已经修改好依赖约束的mypackage/pdf仓库分支，让Composer直接拉取调整后的版本。
     配置完成后在根目录执行composer update tecnickcom/tcpdf setasign/fpdi setasign/fpdi-tcpdf mypackage/pdf mypackage/backend --with-all-dependencies即可。这种方式下Composer会以根目录声明的版本约束为最高优先级，统一完成依赖解析，所有依赖都会安装在根vendor目录，不会生成嵌套文件夹。

避坑提示：不要在mypackage/pdf这类子包目录下单独执行composer require命令，Composer默认只有执行命令的当前目录作为根包时才会生成对应依赖，子包单独执行命令会生成独立的依赖环境，和根项目的自动加载完全割裂，后续运行会出现大量不可复现的问题。
如果你之前已经在mypackage/pdf目录下生成了嵌套vendor目录，直接删除该子目录下的vendor文件夹和composer.lock文件，再按上述方案重新在根目录执行依赖更新即可恢复正常结构。

内容的提问来源于stack exchange，提问作者Nils Fett