如何在Composer中合并多个vendor目录？（特殊架构实现）

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": { ... } } 显式声明所有子模块的命名空间和路径（比如 "PluginFoo": "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 的 path repository 把子模块转为本地开发包，统一由主项目管理依赖

真要硬上多 vendor，别碰 vendor/autoload.php 的二次修改——它每次 dump-autoload 都会被重写。盯紧 composer.lock 和 autoload_psr4.php 的实际内容，比任何文档都准。