Composer不会自动合并composer.json，所谓“中文镜像导致合并失败”是误解；镜像仅代理元数据，不解析或修改本地文件；真实报错源于composer.json与composer.lock不一致、依赖争用字段、旧版Composer兼容问题、网络故障或路径含中文；lock文件冲突应通过删除后重建解决；composer-merge-plugin已废弃且不兼容Composer 2.2+。
Composer根本不会自动合并composer.json
所谓“中文镜像导致自动合并失败”是个误解。Composer 从不自动合并 composer.json 文件，无论你用的是 packagist.org 官方源、阿里云镜像还是腾讯云镜像。镜像只代理元数据（如 packages.json、provider-*.json），它不读、不改、不解析你的本地 composer.json。报错里出现的 “merge conflict in composer.json” 不是镜像造成的，而是 Composer 运行时自己检测到 composer.json 和 composer.lock 内容不一致，或多个依赖争用同一字段（比如都往 autoload.files 里写路径）。
中文镜像只会引发下载/解析类错误，不是合并问题
如果你在用中文镜像时遇到报错，常见真实原因只有这几个：
-
Could not parse version constraint：旧版 Composer（1.x）无法兼容某些镜像返回的精简格式响应，升级到 Composer 2.9.6 可彻底解决 -
Connection refused或超时：镜像服务临时不可用，可临时切回官方源验证：composer config --global repos.packagist.org https://packagist.org -
Invalid argument或failed to open stream：这和镜像无关，是项目路径含中文字符导致 PHP 底层函数（如realpath()）失败 —— 必须把项目根目录、COMPOSER_HOME、PHP 安装路径全部改成纯英文
真正要处理的“合并失败”，其实是 lock 文件冲突
Git 合并时出问题的永远是 composer.lock，不是 composer.json。它结构扁平、字段顺序敏感、含 content-hash 和 platform 快照，手动选一边或删冲突标记都会导致 Your lock file does not contain a compatible set of packages。
标准解法是放弃冲突文件，以合并后的 composer.json 为准重建：
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
- 先确保
git status显示composer.json已 clean（无未提交修改） - 执行
rm composer.lock - 运行
composer install --no-scripts（跳过可能失败的脚本） - 再跑
composer update --lock强制重生成锁文件，不改动composer.json
别碰 composer-merge-plugin，它早就不工作了
这个插件早在 2021 年就停止维护，与 Composer 2.2+ 完全不兼容。启用后典型症状包括：Plugin merge-plugin could not be initialized、Class not found、autoload 映射丢失。它做的“JSON 浅层合并”根本不理解 Composer 的语义规则，比如 require 是覆盖式写入，不是追加。
替代方案只有两个：
- 把共享配置抽成独立私有包，通过
repositories引入，用require声明依赖 - 在 CI 中用
jq或 PHP 脚本动态生成最终composer.json，但绝不把这个生成结果提交进 Git
复杂点在于：所有手工添加的字段（scripts、extra、config）必须放在 Composer 原生支持的顶层键下，且不能嵌套自定义结构——否则下次 composer install 可能静默丢掉它们。
