Composer 不支持合并多个 composer.json 的依赖，因其依赖解析基于单入口且各项目独立；推荐用 path 仓库+单根 composer.json 统一管理，或通过私有 Packagist + git subtree 分发公共包。
Composer 本身不支持“合并多个项目依赖”——它按项目（即每个 composer.json）独立解析依赖树。所谓“多目录结构下合并依赖”，本质是统一管理、避免重复安装或冲突，需靠结构设计和工具链配合，而非 Composer 命令直出。
为什么不能直接用 composer install 合并多个 composer.json
Composer 的依赖解析基于单入口：它只读取当前工作目录下的 composer.json，并递归处理其 require 和 require-dev。多个目录各有一个 composer.json，就等于多个独立项目，强行“合并”会导致：
- 版本冲突无法自动消解（例如 A 项目 require
"monolog/monolog": "^2.0"，B 项目 require"monolog/monolog": "^3.0"，无共同兼容解） -
autoload规则互相覆盖，vendor/autoload.php只能加载一个项目的自动加载逻辑 - 脚本（
scripts）和插件（plugins）作用域混乱，可能触发非预期执行
推荐方案：用 Composer 的 path 仓库 + 单根 composer.json
适用于多个子模块（如 app/、api/、shared/）需要共用依赖、但又保持目录隔离的场景。核心是把子目录当作本地包来引用。
操作步骤：
- 确保每个子目录（如
packages/shared）有合法的composer.json，含name（如"myorg/shared"）和autoload配置 - 在项目根目录的
composer.json中声明repositories：
{
"repositories": [
{
"type": "path",
"url": "./packages/shared"
}
],
"require": {
"myorg/shared": "*"
}
}
- 运行
composer update myorg/shared，Composer 会软链接vendor/myorg/shared→packages/shared，共享源码且复用自动加载 - 所有子模块的依赖最终由根
composer.json统一解析，冲突在根层暴露，可手动约束版本
替代思路：用 composer create-project 拉取模板 + git subtree 管理公共包
适合团队已有稳定基础包（如通用工具库、认证组件），且不希望子项目直接修改其源码。
- 将公共包发布到私有 Packagist 或 Git 仓库，设好
composer.json的type（如"library"） - 各子项目通过
require引入，版本用dev-main或语义化标签控制 - 若需同步修改公共包并立即生效，可用
git subtree push/pull将变更推送到主仓库，再composer update - 注意：不要在子项目中对 vendor 内的包做 git commit —— 它们是构建产物，应从源仓库拉取
容易被忽略的关键点
多目录结构下最常踩的坑不是配置不会写，而是忽略了 Composer 的“作用域边界”：
-
composer dump-autoload -o只作用于当前composer.json所在目录，跨目录需分别执行或改用根 autoload -
autoload-dev不会自动继承给依赖项，测试工具（如 PHPUnit）必须在根项目中统一配置 - 如果用 Docker，
vendor目录不应挂载为 volume —— 多容器并发写入会损坏 autoload 文件 - CI 环境中，
composer install --no-interaction --prefer-dist必须在根目录运行，子目录的composer install是冗余且危险的
