Composer不支持合并依赖，需通过模块拆分、独立包复用或依赖树分析实现整合；直接合并composer.json易引发版本冲突、autoload覆盖等问题。
Composer 本身不支持“合并两个项目依赖”这种操作——它不是包管理器的“合并工具”，而是基于单个 composer.json 解析依赖图并安装。所谓“多模块整合”，本质是组织结构问题，不是 Composer 功能问题。
为什么直接 merge composer.json 会失败
手动拼接两个 composer.json 的 require 字段，大概率触发冲突：
-
symfony/console在 A 项目要求^5.4，B 项目要求^6.2→ Composer 报your requirements could not be resolved - 两个项目都 require 了同名私有包（如
myorg/auth-sdk），但版本约束不同或源不同 → 锁定失败 - 一个项目用
psr-4自动加载App\，另一个也用App\但路径不同 → 类冲突、autoload 覆盖
真实可行的三种整合路径
根据你的目标选择对应方式，没有“通用最优解”：
场景一：想统一管理多个子模块（如微服务/多租户后台）
- 不要把所有
require堆进一个根composer.json - 用
composer create-project或git submodule管理各模块独立仓库 - 在根目录放一个空
composer.json，只定义repositories指向各模块的私有包源（如type: path或type: vcs） - 各模块仍保留自己的
composer.json，通过require引用彼此（如"myorg/user-service": "dev-main"）
场景二：需要复用公共依赖（如 shared lib + app）
- 把可复用代码抽成独立包（哪怕只是本地
type: path） - 在
shared-lib/composer.json中声明"autoload": {"psr-4": {"Shared\\": "src/"}} - 在主项目
composer.json的repositories加：{ "repositories": [ { "type": "path", "url": "../shared-lib" } ], "require": { "myorg/shared-lib": "*" } } - 运行
composer update myorg/shared-lib触发 autoload 重生成
场景三：临时调试两个项目依赖兼容性
- 不用改任何
composer.json，直接用composer show --tree分别查看依赖树 - 对比关键包（如
guzzlehttp/guzzle、laravel/framework）的解析版本是否一致 - 若不一致，用
composer prohibits vendor/package:version查谁在锁死旧版本 - 必要时加
"minimum-stability": "dev"和"prefer-stable": true平衡兼容与稳定性
autoload 冲突比依赖冲突更隐蔽
即使 composer install 成功，类自动加载也可能出错：
- 两个模块都注册了
"App\\": "app/"，但实际路径不同 → 后注册的覆盖前注册的 - 使用
classmap时未运行composer dump-autoload --optimize→ 新增类不被识别 - 模块间存在循环 autoload（A require B，B 的 autoload 又 require A 的类）→
Class not found且无明确提示
验证方式：删掉 vendor/autoload.php，手动 require 各模块的 autoload.php，观察报错顺序。
真正难的从来不是怎么写配置，而是厘清模块边界——哪些该拆成包，哪些该共用 autoloader，哪些必须隔离运行时。Composer 不替你做架构决策，只忠实地执行你写的约束。
