如何解决Composer处理lock文件冲突及Git合并冲突问题，促进团队协作？

本文共计899个文字，预计阅读时间需要4分钟。

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 分支 require ext-imagick，合并后没显式声明，CI 构建直接挂

正确做法：先还原 lock，再让 Composer 重生成

核心原则：不编辑 lock 文件本身，而是用 composer update 或 composer install --no-scripts 让工具重新计算依赖图。