composer.lock 合并冲突不能自动解决，因其是依赖树的精确快照，字段顺序敏感、哈希微变即整块重写；应放弃冲突文件，以合并后的 composer.json 为准运行 composer install 重建锁文件。
为什么 composer.lock 合并冲突不能靠自动解决
Git 自动合并 composer.lock 文件大概率失败，因为它是完整依赖树的精确快照，字段顺序敏感、嵌套深、哈希值微小变动就导致整块重写。一旦两个分支各自运行过 composer install 或 composer update，锁文件结构几乎必然不兼容。
直接保留某一方或用 Git 工具“选中”某段内容，极可能造成：
– 依赖版本与 composer.json 不匹配
– vendor/ 目录实际安装状态和锁文件记录不一致
– CI 构建时因哈希校验失败而中断
- 不要手动编辑
composer.lock的 JSON 结构（比如删字段、调顺序） - 不要在冲突后直接
git add composer.lock提交 - 冲突不是“选左边还是右边”的问题，而是“哪次依赖变更才是预期的”问题
先还原再重演：用 composer install 重建锁文件
最稳妥的做法是放弃冲突文件，以当前 composer.json 为准，重新生成锁文件——前提是你的 composer.json 本身已正确合并且无冲突。
操作步骤：
- 执行
git checkout --ours composer.json（确保你保留了合并后正确的composer.json） - 删除当前冲突的
composer.lock：rm composer.lock - 运行
composer install --no-dev（加--no-dev可跳过开发依赖，加快速度；若需 dev 包则去掉） - 检查输出：确认没有
Warning: The lock file is not up to date类提示，且所有包版本与预期一致 -
git add composer.lock并提交
这个流程本质是把“合并锁文件”转化为“基于确定的 composer.json 生成新锁”，绕开了 JSON 结构比对难题。
如果必须保留某次 update 的变更怎么办
有时 A 分支升级了 monolog，B 分支升级了 guzzlehttp，你希望两者都生效。此时不能靠合并锁文件，而要明确触发两次变更：
- 先确保
composer.json已包含两组变更（比如"monolog/monolog": "^3.0"和"guzzlehttp/guzzle": "^7.8"） - 运行
composer update monolog/monolog guzzlehttp/guzzle --with-all-dependencies，显式指定要更新的包 - 加上
--with-all-dependencies是防止因依赖约束引发意外降级或跳过子依赖更新 - 完成后检查
composer.lock中对应包的version和source/reference是否符合预期
注意：composer update 会重新解析整个依赖图，不是“叠加”两次更新，所以必须确保 composer.json 的声明是最终想要的状态。
CI/CD 中避免锁文件冲突的根本办法
频繁出现锁文件冲突，说明团队在依赖管理上缺乏同步节奏。可从流程上降低发生概率：
- 禁止在 feature 分支中随意运行
composer update；所有依赖变更应经由专人评审后合入main分支 - 在 CI 流程中加入校验步骤：
composer install --dry-run，若报错说明composer.lock和composer.json不匹配，立刻失败 - 使用
composer normalize（需安装jean85/composer-normalize）统一格式，虽不能解决语义冲突，但能减少因空格、换行、键序导致的无谓差异
锁文件不是普通配置文件，它的权威性来自 composer install 的执行结果。任何绕过该过程的手动干预，都在给后续部署埋雷。
