composer.lock 文件一合并就冲突，因其精确记录依赖版本、哈希值、路径及嵌套关系，任何 update/require/Composer 升级/跨系统操作都会导致字段顺序、空格或结构变化，引发真实内容分歧而非误报。
Composer.lock 文件为什么一合并就冲突？
因为 composer.lock 是一个精确记录所有依赖包版本、哈希值、安装路径和嵌套依赖关系的 JSON 文件，任何 composer install、composer update 或甚至不同 Composer 版本生成的 lock 文件，都会导致字段顺序、空格、哈希值或依赖树结构发生微小但确定性的变化。
多人并行开发时，只要两个人各自执行过 composer require 或 composer update，哪怕只改了一个包，Git 就大概率在 composer.lock 上产生三路合并冲突——这不是误报，是真实的内容分歧。
哪些操作会直接触发 lock 文件变更？
以下行为只要发生一次，就会重写整个 composer.lock（且无法跳过）：
-
composer update（即使没指定包，也会刷新所有已锁版本的哈希与时间戳） -
composer require vendor/package或composer remove vendor/package - 升级 Composer 本身（v2.2 → v2.5 可能改变字段排序或新增字段）
- 在不同操作系统（Linux/macOS/Windows）上运行
composer install，可能因换行符或路径分隔符影响生成逻辑
如何减少冲突 + 安全解决已有冲突？
核心原则：不手动编辑 composer.lock，不接受 Git 合并工具的“保留双方”结果，必须由 Composer 重新生成权威版本。
推荐流程如下：
- 合并前，先运行
composer install确保本地 lock 和 vendor 一致；再git add composer.lock提交干净状态 - 遇到冲突时，**立刻丢弃当前 lock 文件内容**：
git checkout --theirs -- composer.lock composer install --no-scripts
这会用对方分支的 lock 重建 vendor，并验证其有效性 - 如果想以自己分支为准，用
git checkout --ours -- composer.lock，再跑composer install - 若双方都改了依赖，最稳妥的是：删掉冲突后的
composer.lock，用主干composer.json重新生成 —— 先切到目标基线分支（如main），composer install生成 clean lock，再切回你的功能分支，composer require xxx增加所需依赖，让 Composer 自动合并进新 lock
长期规避策略：团队协作约定
冲突频繁的根本原因是缺乏同步节奏。建议明确三条底线：
- 禁止直接修改
composer.json后不跑composer install就提交 —— 每次composer.json变更，必须附带对应更新的composer.lock - 每天早间固定一人执行
composer update --dry-run检查是否有安全更新，确认后统一执行composer update并推送到main，其他人基于该 commit 继续开发 - CI 流程中加入校验：
composer install --no-scripts && git diff --quiet composer.lock || (echo "composer.lock not up to date" && exit 1)
防止漏提 lock 文件
真正麻烦的不是冲突本身，而是有人在冲突后手动删掉几行 JSON、或者用 IDE 合并工具“选左边+选右边”拼出一个 Composer 根本无法解析的 lock 文件——那会导致整个 CI 卡住，且错误信息只显示 file could not be parsed，排查成本远高于预防。
