composer不支持多vendor目录合并，因其无原生多路径叠加机制；强行共存会导致autoload失效、类找不到及依赖冲突。推荐方案是分装后统一dump-autoload，或用path repository统一管理。
Composer 不支持多 vendor 目录合并
Composer 本身没有 vendor-dir 多路径、叠加或“合并”机制。所谓“多个 vendor 目录”，实际是项目结构或部署流程中人为拆分的结果，不是 Composer 原生能力。强行让多个 vendor 目录共存并被自动识别，会导致 autoload 失效、类找不到、依赖冲突升级等确定性问题。
用 composer install --no-autoloader + 手动合并 autoload
这是最可控的折中方案：先分别安装各 vendor，再统一生成 autoload 映射。适用于你有多个独立 composer.json（如插件目录、模块子包），但最终要跑在一个主应用里。
- 每个子目录单独执行
composer install --no-autoloader，避免重复生成vendor/autoload.php - 主项目
composer.json中用"autoload": { "psr-4": { ... } }显式声明所有子模块的命名空间和路径（比如"Plugin\Foo\": "plugins/foo/src/"） - 运行
composer dump-autoload，它会把所有声明的路径一并扫描进主vendor/autoload.php - 注意：子目录不能有同名包（如都含
monolog/monolog），否则composer install会报错或覆盖
用 composer create-project 拉取子包到非-vendor 路径后手动 require
适合轻量级扩展，比如主题、钩子脚本等不依赖复杂 autoloading 的场景。绕过 vendor 管理，靠 PHP 原生 require 或 spl_autoload_register 补位。
- 用
composer create-project vendor/name ./extensions/name --no-install下载源码但不执行 install - 在主项目入口前手动
require './extensions/name/vendor/autoload.php'（如果子包自带 autoload） - 更稳妥的做法是只
require子包的单个核心文件，避免 autoload 冲突 - 缺点明显：无法享受 Composer 的版本约束、更新、依赖解析，后续维护成本陡增
真正需要“合并 vendor”的时候，通常暴露了架构问题
比如多个团队各自维护 vendor、线上环境限制写权限、或试图复用本地开发的第三方包。这些都不是 Composer 的设计边界——它假设一个项目一个 vendor，且依赖树是单向可解的。
- 多 vendor 往往伴随
Class 'X' not found或Cannot redeclare class，根源是include_path或autoloader加载顺序混乱 - CI/CD 中若用不同机器 install，结果不可重现，因为各 vendor 目录时间戳、扩展顺序、PHP 版本微差都会影响
autoload_classmap.php生成 - 最省事的长期解法：用 Composer 的
pathrepository 把子模块转为本地开发包，统一由主项目管理依赖
真要硬上多 vendor，别碰 vendor/autoload.php 的二次修改——它每次 dump-autoload 都会被重写。盯紧 composer.lock 和 autoload_psr4.php 的实际内容，比任何文档都准。
