直接删冲突标记并手动改composer.lock最危险，因其是依赖图哈希快照，字段错即导致install失败；应先解决composer.json冲突，再用composer update --lock重建合法lock文件。
直接删掉冲突标记再手动改 composer.lock 是最危险的操作
因为 composer.lock 不是配置文件，而是整个依赖图的哈希快照。哪怕只改错一个 content-hash 字段，下次 composer install 就会拒绝执行，报错类似 Your lock file does not contain a compatible set of packages。Git 合并时出现的 和 <code>>>>> branch-name 标记一旦残留，JSON 就非法，连 composer validate 都过不了。
先确认 composer.json 是否也冲突
如果 composer.json 本身有未解决的差异，composer.lock 冲突根本没法安全处理。必须优先合并或理清 composer.json 的变更，尤其是：
-
require和require-dev区块里新增/删除的包名和版本约束 -
platform下的 PHP 或扩展版本声明是否被某一方修改 - 有没有启用
"sort-packages": true—— 没启用的话，两个分支装同一组包也可能因顺序不同触发“假冲突”
运行 composer validate 能快速暴露 composer.json 语法或逻辑问题；若提示 lock file has some errors，说明它已不可信，别再试图修它。
用 composer update --lock 重建，而不是 composer install
很多人误以为 composer install 能“恢复”锁文件，其实它只负责按现有 composer.lock 安装，不生成也不修复。真正该用的是：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
git checkout --ours composer.lock或git checkout --theirs composer.lock（任选其一，临时还原为合法 JSON） -
rm -rf vendor/（确保干净，避免残留影响） -
composer update --lock（关键：不带包名，仅重算哈希、校验依赖树、生成新 lock）
这个命令不会升级任何包，只同步当前 composer.json 所需的完整依赖结构。它比 composer install 更适合“恢复”场景，因为后者在 lock 损坏时直接失败，而前者能主动重建。
CI/CD 流水线里别信 GitHub 的“Resolve conflicts”按钮
GitHub/GitLab 的 Web 界面自动合并建议对 composer.lock 完全无效。它只会做纯文本合并，不校验包哈希、不检查子依赖是否兼容、不验证 platform-check 值。CI 构建失败十有八九源于此。更稳的做法是：
- 在项目根目录加
.gitattributes，写入composer.lock merge=ours（主干优先策略）或merge=theirs（功能分支优先） - CI 脚本开头加
composer install --dry-run，失败即中止，倒逼开发者本地先跑通 - 禁止在 CI 中执行
composer update—— 它会绕过 lock，导致环境漂移
真正难处理的从来不是冲突本身，而是团队里有人把 composer.lock 当成普通 JSON 来 commit、diff、rebase。它只该由 Composer 生成，也只该由 Composer 修改。
