git合并冲突后composer.json残留
Git 合并冲突后 composer.json 报 JSON 错误，根本不是 Composer 的问题，而是文件里残留了 、<code>=======、>>>>> origin/main 这类标记——JSON 解析器直接拒识，连行号都懒得报。
怎么一眼识别是 Git 冲突没清理干净
打开 composer.json，用编辑器开启「显示不可见字符」或直接搜 。只要看到任何类似 <code> 的行，就不用再跑 <code>composer validate 了——它必然失败，且错误信息常是模糊的 JSON decoding failed: Syntax error 或直接卡死。
常见现象：
-
composer install报file could not be loaded，但git status显示composer.json是clean -
composer validate提示Parse error on line 1，实际文件开头看着正常（其实是 BOM + 冲突标记混在一起） - 用
jq empty composer.json报错如Invalid string: control characters，定位到第一行
删标记？不，直接丢弃重来最安全
别手动删冲突标记、别对齐缩进、别“差不多就行”。Git 冲突后的 JSON 结构已不可信，字段顺序、逗号、括号嵌套全可能错乱，强行修容易触发 content-hash 校验失败，后续 composer install 会静默装错包。
正确做法分三步：
- 确认当前分支状态：
git status看composer.json是否在Unmerged paths下 - 用 Git 强制回退到任一干净版本：
git checkout --theirs composer.json（取远端）或git checkout --ours composer.json（取本地），二者选其一即可 - 立刻验证：
composer validate --no-check-publish，通过后再决定是否需同步更新composer.lock
为什么不能只修 composer.json 就跑 install
composer install 完全依赖 composer.lock，而 Git 冲突时 composer.lock 往往也已损坏或过期。即使 composer.json 恢复干净，lock 文件若仍含冲突残留或哈希不匹配，命令会失败或降级安装旧版依赖。
推荐组合操作：
- 如果 lock 文件也被标为 modified：
rm composer.lock && composer install（重建 lock） - 如果想保留当前 vendor 状态但刷新 lock：
composer update --lock（仅重算哈希，不改已装包） - CI/CD 流水线中必须加校验：
jq empty composer.json && composer validate --strict，任一失败即中断
团队协作时怎么避免下次再踩坑
根本解法不是教大家怎么修冲突，而是让冲突压根不进 composer.json。关键动作：
- 所有依赖增删统一走
composer require vendor/package或composer remove vendor/package，禁止手写require块 - 把
composer.json加入.gitattributes：设置composer.json merge=union（慎用）或更推荐merge=ours，强制 Git 冲突时保留本地版本，靠后续composer update对齐 - 启用 pre-commit hook：用
composer validate --no-check-publish+jq empty composer.json双校验，不通过不准提交
真正麻烦的从来不是冲突本身，而是修复后没人检查 composer.lock 是否与新 composer.json 对得上——这个差半拍的间隙，就是线上环境 autoload 失败、类找不到的起点。
