Composer提示“merge conflict in composer.json”实为配置不一致而非Git冲突，需删composer.lock重生成、用composer require/config命令安全修改、避免手动合并JSON，弃用已停更的composer-merge-plugin。
composer install 时提示 “merge conflict in composer.json” 怎么办
这不是 Git 冲突，而是 Composer 自己检测到 composer.json 和 composer.lock 不匹配，或多个依赖间接修改了同一段配置（比如都试图写 autoload 或 scripts）。常见于团队协作后手动改了 composer.json，又没跑 composer update 就直接 composer install。
实操建议：
- 先确认是否真有未提交的本地修改：
git status看composer.json和composer.lock是否被标为 modified - 如果只是
composer.lock过期，直接删掉它再运行composer install—— Composer 会按当前composer.json重建 lock 文件 - 如果
composer.json确实被多人改过（比如两个 PR 都加了require-dev），别手动合并 JSON，用composer require xxx或composer config命令追加，让 Composer 自己处理结构一致性
如何安全合并多个包的 autoload 配置
第三方包（尤其是插件类库）常在自己的 composer.json 里声明 autoload，而你的项目也定义了 psr-4 或 files。Composer 默认会把它们“叠加”，但顺序和路径冲突会导致类找不到或函数重复定义。
实操建议：
- 不要在主
composer.json的autoload.files里硬塞第三方的functions.php—— 优先让包自己管理加载逻辑 - 检查冲突：运行
composer dump-autoload -v，看输出里是否出现Warning: Ambiguous class resolution - 若必须覆盖某包的自动加载规则，用
autoload-dev+exclude-from-classmap显式排除其目录，再用自己的规则接管
composer merge-plugin 不再维护，替代方案怎么选
composer-merge-plugin 曾被用来动态合并多个 composer.json（如模块化项目），但它早在 2021 年就停止维护，且与 Composer 2.2+ 的插件机制不兼容，启用后会报 Plugin installation failed 或静默失效。
实操建议：
- 放弃合并配置文件的思路 —— Composer 本就不鼓励“多入口 json”。模块应作为独立包发布，通过
require引入 - 如果必须共享配置（如多个子项目共用一套
autoload规则），抽成一个私有包，在它的composer.json中定义autoload，其他项目require它即可 - CI/CD 场景下需要生成最终配置？用脚本（PHP/Python）读取多个 JSON 合并后写入临时
composer.json，再调composer install—— 但别把合并结果提交进 Git
为什么 vendor/autoload.php 加载顺序会影响行为
Composer 生成的 vendor/autoload.php 是个“加载器链”，它按 composer.json 中 autoload、autoload-dev、各依赖包的 autoload 顺序注册 PSR-4/PSR-0/classmap/files。顺序错位会导致：你写的同名类被包里的类覆盖，或 files 提前执行却依赖未加载的类。
实操建议：
- 永远把项目自身的
autoload放在主composer.json顶层，不要藏在require-dev下 - 避免在
files中 require 其他包的文件 —— 它们加载时机不可控；改用classmap或 PSR-4 - 调试加载顺序：临时在
vendor/autoload.php开头加echo "loaded\n"; exit;，观察哪一行先触发
composer.json 里的一行 config（比如 process-timeout）或 scripts（比如 post-install-cmd）会被依赖包的同名字段覆盖 —— 这种覆盖不报错，只默默失效。 
