不能随便选 ours/theirs，因为 composer.lock 精确记录依赖树、哈希值等，直接覆盖会导致 vendor/ 与锁文件不一致，引发 hash 错误或静默升降级；应通过 composer update –lock 或 composer install –no-interaction 重建锁文件。
为什么 composer.lock 冲突不能随便选 ours/theirs
因为 composer.lock 不是普通配置文件，它精确记录了每个包的完整依赖树、哈希值、安装路径和平台约束。用 git checkout --ours 或 git checkout --theirs 直接覆盖，极大概率导致本地 vendor/ 与锁文件不一致，后续 composer install 会报 Package xyz has a mismatched hash 或静默降级/升级某些包。
- 冲突常出现在团队多人同时
composer require、composer update后提交 - Git 只按文本行比对，但 lock 文件中同一包在不同分支可能被插入到不同位置，或哈希字段顺序微调，造成大量“假冲突”
- 手动编辑 lock 文件极易出错——少一个逗号、错一位 hex 字符，
composer install就直接失败
正确做法：用 Composer 自身重建锁文件
核心原则：放弃解决文本冲突，让 Composer 基于当前 composer.json 重新生成一份干净、一致的 composer.lock。
- 先确保你的
composer.json已合并完成（无冲突），且内容是你期望的最终状态 - 运行
composer update --lock：它不会更改任何已声明的依赖版本，仅重写 lock 文件以匹配当前composer.json和已安装的 vendor（如果存在） - 若你刚 rebase 完且
vendor/被清空，改用composer install --no-interaction，它会严格按现有 lock 文件还原 —— 但前提是 lock 文件本身得能解析；若 lock 文件语法损坏，必须先删掉再跑composer update --lock - 生成后，
git add composer.lock并继续 rebase（git rebase --continue）
rebase 过程中提前预防 lock 冲突
不是所有冲突都必须等到了 rebase 中才处理。主动控制 lock 文件变更节奏，能大幅减少麻烦。
- 避免在 feature 分支里执行
composer update；只做composer require xxx或composer remove xxx，这些操作只会改composer.json并触发一次composer update --lock - 在合并前，让 CI 或某位成员统一在
main分支上运行composer update --lock，再把新 lock 提交上去；其他分支 rebase 时只需同步这个单次变更，冲突概率骤降 - 启用
"lock": true在composer.json的config段（Composer 2.2+），强制所有composer install行为都校验 lock 文件完整性，提前暴露不一致
CI 环境下自动修复 lock 冲突的脚本思路
如果你的 CI 流水线在 rebase 后检测到 composer.lock 冲突，可以加一段恢复逻辑，而不是让构建卡住。
- 检查是否处于 rebase 中：
git rev-parse --verify REBASE_HEAD > /dev/null 2>&1 - 若 lock 文件有未解决冲突（含 git checkout –theirs — composer.lock（仅临时取远端版本，不提交）
- 立即运行
composer update --lock --no-interaction，覆盖为合法 lock - 再
git add composer.lock，并git rebase --continue（需配合 CI 支持交互式 rebase 的配置） - 注意：该流程要求 CI 环境的 Composer 版本与项目兼容，且
composer.json必须已无冲突
真正难的不是怎么 merge，而是让 lock 文件的变更始终可预测、可追溯。一旦放任多人各自 update，再强的 rebase 技巧也救不了散掉的依赖一致性。