Composer本身不提供依赖自动合并功能；composer-merge-plugin是第三方插件，仅在运行时合并多个composer.json配置到内存依赖图，不参与版本解析或冲突仲裁，合并后字段按“后出现覆盖”原则生效。
Composer 本身不提供“依赖包自动合并”功能，所谓“自动合并”是误传或对插件行为的误解；真正能接近该效果的，只有 composer-merge-plugin 这类第三方扩展，且它只在运行时合并配置，不改变依赖解析逻辑。
composer-merge-plugin 是什么，它真能“合并依赖”？
它是一个 Composer 插件，允许你在主 composer.json 中通过配置引入其他 JSON 文件（如 packages/*.json），并在执行 composer install 或 composer update 前，把它们的内容合并进内存中的依赖图。但它不修改原始文件，也不参与版本冲突仲裁——只是提前拼接输入。
- 它不替代 Composer 的依赖求解器，
require冲突仍由原生逻辑报错 - 合并后字段遵循“后出现覆盖”原则，比如两个文件都定义了
extra.deploy，后者生效 - 不支持递归合并嵌套的
repositories，需手动展平路径 - Composer 2.2+ 已弃用部分钩子，某些旧版插件配置会静默失效
为什么直接改 composer.json 手动合并 require 字段容易出错？
因为 require 和 require-dev 不是简单列表拼接，而是约束表达式集合；同名包不同版本范围可能互斥，导致后续 composer update 直接失败或降级核心组件。
- 例如 A 项目写
"laravel/framework": "^10.0"，B 项目写"laravel/framework": "^11.0"，合并后 Composer 无法同时满足，报Your requirements could not be resolved -
minimum-stability和prefer-stable若不统一，可能让某个模块意外拉取dev-main分支 -
conflict字段若被忽略，会导致看似兼容、实则运行时报错的隐性冲突 - 别忘了
replace字段：两个模块若都声明替换psr/log，合并后只剩最后一个生效，可能破坏自动加载
path 类型 repositories + 多 composer.json 的真实用途
这不是“合并依赖”，而是模块化管理：把子目录当独立包看待，由主项目显式声明依赖关系。Composer 会分别解析每个 composer.json，再统一做依赖收敛。
- 子模块的
name必须与主项目require中的包名完全一致，否则报Package not found -
path仓库不支持通配符，"url": "modules/*"无效，必须逐个列出 - 子模块中若有
autoload，其 PSR-4 映射默认相对于自身根目录，不是主项目根目录 - CI 环境中若未清理 vendor 缓存，可能复用旧模块的已安装版本，跳过重新解析
composer.lock 文件在多配置场景下的关键角色
无论你用插件合并、path 引用还是纯手工编辑，composer.lock 始终是唯一可信的安装快照。它记录了每个包的确切版本、哈希和来源，一旦缺失或过期，所有“合并”效果都会失效。
- 多人协作时，必须提交
composer.lock，否则composer install在不同机器上结果不一致 - 使用
composer-merge-plugin后，composer.lock里会包含所有被合并文件的 hash，但不会体现这些文件路径——调试时容易误判来源 - 执行
composer update --lock只刷新时间戳和哈希，不变更版本；但若合并逻辑变了（比如删了一个子配置），这个命令不会触发重算，得删 lock 后重装 - 私有包若通过
path引入，其代码变动不会自动触发主项目重装，除非手动改子模块的version或加dev-前缀强制刷新
最常被忽略的一点：所有“合并”手段都不影响 Composer 的依赖求解顺序。它永远从主 composer.json 出发，按拓扑排序展开，子模块只是被当作远程包处理——这意味着，哪怕你把 Laravel 框架拆成 10 个 path 包，它的核心约束依然由主文件中那一行 "laravel/framework" 控制，其余只是补充。
