必须用 composer update --lock 重建 lock 文件，因其按 composer.json 重算哈希与依赖，不依赖已冲突的旧 lock；手动修改或保留合并标记必致解析失败、校验不通过或运行时异常。
Composer 的 composer.lock 文件冲突不能靠手动删标记解决——它不是普通代码文件，而是精确的依赖快照，必须用 Composer 自身逻辑重建。
为什么 composer.lock 冲突不能像 PHP 文件那样手修
Git 把 composer.lock 当作纯文本处理，但它的结构是严格按依赖解析顺序生成的 JSON，包含哈希、版本、平台约束等元信息。手动删掉 <<<<<< HEAD 块后保留任意一方内容，大概率导致：
- 依赖树不一致：A 分支装了
monolog 2.10.0，B 分支装了2.11.0，你只留一个，composer install可能失败或降级 - 哈希校验失败：
composer install会比对 lock 中的dist.shasum和实际下载包，错位就报Invalid checksum - PHP 扩展要求冲突：比如 A 分支 require
ext-gd，B 分支 requireext-imagick，合并后没显式声明，CI 构建直接挂
正确做法：先还原 lock，再让 Composer 重生成
核心原则：不编辑 lock 文件本身，而是用 composer update 或 composer install --no-scripts 让工具重新计算依赖图。操作分三步：
- 用
git checkout --ours composer.lock或git checkout --theirs composer.lock暂时恢复任一版本（选更接近当前开发环境的那个） - 运行
composer update --lock—— 这个命令不改composer.json，只根据当前json和已安装包，重写lock文件 - 如果项目有多个环境（dev/prod），加
--with-dependencies确保子依赖也被刷新；CI 上建议加--no-interaction --no-progress
团队协作中必须统一的配置点
很多 lock 冲突其实源于本地环境差异，不是代码问题。以下三项必须在团队内对齐：
-
platform配置：在composer.json里显式声明"config": {"platform": {"php": "8.2.10"}}，避免有人本地是 PHP 8.3 导致 lock 里写入不兼容扩展 - 插件行为：禁用
fxp/composer-asset-plugin等已废弃插件，它们会干扰 lock 生成顺序 - Git 行尾处理：确保
.gitattributes包含composer.lock text eol=lf，否则 Windows 和 macOS 用户提交的换行符差异会触发无意义冲突
CI/CD 流水线里怎么防住 lock 冲突
上线前自动检测比人工 merge 更可靠：
- 在 PR 检查中加一步：
composer validate --strict && composer install --dry-run，验证 lock 是否合法且可复现 - 禁止直接
git push到主干分支，所有合并必须走composer update --lock+git add composer.lock+ 提交 - 如果使用 GitHub Actions，用
composer-normalizeaction 格式化 lock，消除字段顺序差异引发的“假冲突”
最易被忽略的是：很多人以为 composer.lock 冲突只要两边都跑一遍 install 就能自动同步——实际上，install 不会修改 lock，它只按 lock 安装；只有 update 或手动改 json 后再 update 才会重写 lock。
