先理解文件作用再解决冲突。composer.json声明依赖，需手动合并并验证；composer.lock记录精确版本，应通过composer update --lock重建以确保一致性，避免手动修改。
处理 Composer 项目中的合并冲突，尤其是 composer.json 和 composer.lock 文件的冲突，关键在于理解文件作用并采取协作友好的策略。直接覆盖或随意修改可能破坏依赖一致性，影响团队和生产环境。
理解两个核心文件的角色
composer.json 定义项目所需的依赖及其版本约束，是手动编辑的声明文件；composer.lock 记录当前安装的确切版本，保证所有环境依赖一致，通常由 Composer 自动生成和更新。
合并冲突常出现在多人同时添加、更新或移除包时。解决时需兼顾功能需求与依赖稳定性。
安全解决 composer.json 冲突
当 composer.json 出现冲突，应逐一核对双方更改：
- 列出所有新增的依赖，确认是否都必要，避免重复引入同类库
- 检查版本约束（如 ^2.0 或 ~1.5），若存在差异，选择兼容性更强且满足需求的写法
- 如有删除项，确认是否已被替代或确实不再需要
手动合并后，建议运行 composer validate 检查语法正确性。
合理处理 composer.lock 冲突
不要手动编辑 lock 文件来解决冲突。最稳妥的方式是接受一方的 lock 文件，然后重新执行 composer install 或根据合并后的 json 执行 composer update。
推荐做法：合并完 composer.json 后，直接运行：
composer update --lock这会根据最新的 composer.json 重新生成 composer.lock，确保两者同步且依赖解析正确。
预防胜于治疗：团队协作规范
减少冲突的根本方法是建立团队习惯：
- 在功能分支完成后再执行 composer require，避免频繁变更主分支依赖
- 提交依赖变更时附带说明，便于他人理解修改意图
- 定期同步主干更新，降低长期分支带来的合并复杂度
基本上就这些。关键是保持 lock 文件与 json 一致，并通过标准流程重建 lock，避免“谁的提交最后谁生效”的粗暴方式。
