composer.lock冲突不能直接选ours/theirs，因其content-hash依赖composer.json、PHP版本及扩展配置，packages数组记录精确包哈希；盲目采用单方lock会导致环境不一致、CI失败或运行时错误。
多人协作时 composer.lock 文件出现哈希冲突，不是“随便选一边”或“重装依赖”就能解决的——它本质是依赖图不一致的信号，必须验证实际依赖是否兼容。
为什么 composer.lock 冲突不能直接用 ours/theirs？
composer.lock 不是普通配置文件，它的 content-hash 字段由 composer.json 内容、PHP 版本、平台配置（如 ext-mbstring 是否启用）共同决定；而 packages 数组记录的是每个包确切的源码 commit、dist URL 和哈希值。直接取某一方的 lock 文件，可能导致：
- 本地
composer install安装出和对方环境不同的包版本（尤其当双方 PHP 小版本不同或扩展启停状态不一致时） - CI 构建失败：CI 环境可能校验
content-hash与composer.json是否匹配，不一致则拒绝安装 - 隐性运行时错误：比如 A 合并了
monolog/monologv2.10.0，B 的 lock 里却是 v3.0.0，但双方composer.json都只写了"^2.0 || ^3.0"—— 表面兼容，实际 API 差异已存在
正确合并流程：三步验证法
目标是让 composer.lock 反映当前 composer.json 在**你本地环境**下可复现、可部署的真实依赖状态：
-
第一步：暂存冲突，还原干净工作区
执行git checkout --ours -- composer.json && git checkout --theirs -- composer.lock（或反之），再运行composer install --no-scripts。这会按当前composer.json重新生成 lock，但跳过脚本（避免误触发迁移命令） -
第二步：比对关键字段差异
用git diff对比新旧composer.lock，重点关注：
–content-hash是否变化（若没变，说明依赖图未实质变动）
–packages数组中冲突涉及的包（如"vendor/package-name"）的version、source/reference、dist/shasum -
第三步：确认变更影响范围
对有差异的包，查其composer.json中的require和conflict字段（用composer show vendor/package-name或直接看 Packagist 页面），判断版本升级是否引入不兼容变更（例如从 v1.x 升到 v2.x 的 major bump）
常见陷阱与绕过方案
有些团队试图用 composer update --lock 强制刷新 lock，但这会忽略 composer.json 中的版本约束，可能升级到非预期版本；还有人删掉 composer.lock 再 install，等同于放弃可重现性。
- 如果冲突来自 CI 自动更新（如 Dependabot PR），先检查该 PR 的
composer.json是否真被修改过——有时只是 lock 文件被机器人重写，composer.json实际未变，此时应以composer.json为准，运行composer update --lock并提交新 lock - 若团队跨 PHP 版本开发（如本地 PHP 8.2，CI 用 PHP 8.1），
content-hash必然不同。此时应在composer.json中显式声明"config": { "platform": { "php": "8.1" } }，统一平台假设 - 遇到
"Your requirements could not be resolved to an installable set of packages"错误，说明双方composer.json存在隐性冲突（例如一个加了"foo/bar": "^1.0"，另一个加了"foo/bar": "^2.0"）。必须先协调composer.json，再生成 lock
自动化辅助建议
把 lock 文件校验纳入开发流程能减少人工疏漏：
- 在
pre-commit钩子中加入：composer validate --strict && composer install --dry-run
，确保本地修改后 lock 仍合法且可安装 - CI 中添加步骤：
composer install --no-scripts && composer show --locked | grep -E '^(name|version)'
，用于快速审计关键依赖版本是否符合预期 - 对高频冲突包（如
laravel/framework），可在composer.json中用"prefer-stable": true+"minimum-stability": "stable"降低 dev 分支引入概率
真正难的从来不是解决冲突，而是识别冲突背后是否藏着未对齐的依赖策略、PHP 环境假设或版本升级意图。每次 merge composer.lock 前，多看一眼 content-hash 和具体包的 shasum，比盲信 git 解决方案更可靠。
