composer.lock冲突不能手动解决，因其是依赖快照而非普通配置文件；手动编辑会破坏JSON结构、哈希校验或包顺序，导致install失败或运行时错误；必须以合并后的composer.json为唯一源，运行composer update --lock重建。
直接结论：composer.lock 文件不是“可合并”的普通配置文件，冲突时不能手动编辑，必须丢弃并重建；团队环境一致性的前提是所有人只运行 composer install，且 composer.lock 必须提交、不可忽略。
为什么不能手动解决 composer.lock 的 Git 冲突
冲突块里混入 会破坏 JSON 结构，<code>composer install 直接报 JSON decode error；即使侥幸解析成功，packages 数组顺序错乱、dist.sha256 哈希不匹配，会导致类加载失败或行为不一致。Composer 不校验 lock 语法，只在 install/update 时重生成并比对——你改的不是文本，是依赖图的快照。
- 手动删冲突标记、保留部分包版本 → 锁文件语义失效，后续
composer install可能静默跳过某些包 - 用
git checkout --ours或--theirs强行保留某一方 → 实际依赖状态已偏离对方composer.json，install 会失败或装出错误版本 - 用在线 JSON 工具“美化”后合并 → 换行符、字段顺序、空格被重排，触发大量“假冲突”，掩盖真实差异
冲突发生后最稳妥的重建流程
核心是放弃 lock 文件本身，以双方 composer.json 合并后的最终状态为唯一可信源，让 Composer 重新生成 lock。
- 先
git fetch origin && git merge origin/main（或 rebase），确保composer.json已整合双方变更（如新增"monolog/monolog": "^3.0"） - 删掉本地
vendor/和composer.lock（避免残留缓存干扰） - 运行
composer update --no-install：只更新 lock，不重装 vendor，输出里检查是否出现非预期的降级或跳过包 - 确认无误后
git add composer.lock并提交，附带清晰描述（如 “lock: sync monolog ^2→^3 + fix php 8.3 platform constraint”）
怎么从源头减少 composer.lock 冲突频率
高频冲突本质是多人无序修改依赖。关键不是限制操作，而是统一节奏和验证点。
- 禁用
composer update全量更新，改用composer update vendor/package-name --with-dependencies精确控制影响范围 - 启用
"config": { "sort-packages": true }，让 lock 文件按字母序固定排列，消除因包顺序不同导致的“假冲突” - CI 流程中加
composer install --dry-run校验：若失败，说明有人改了composer.json却没提交新 lock，立即阻断合并 - 功能分支里完成依赖变更后，尽快合入 main，避免长期 diverge 导致
composer.json差异过大
composer install vs composer update 在团队中的实际分工
composer install 是日常命令，composer.update 是受控升级动作——两者语义完全不同，混用是环境不一致的主因。
-
composer install：所有开发机、CI 构建、测试环境、生产部署都必须用它；它读 lock 文件，保证装出来的版本 100% 一致 -
composer update：只在明确需要升级时由专人执行（如修复 CVE、升 Laravel 主版本、适配 PHP 8.4）；执行后必须立刻提交新composer.lock - CI 脚本里出现
composer update是严重违规，除非是独立的安全审计任务；否则每次构建都可能装出不同版本，埋下“在我机器上没问题”的隐患
真正难的不是操作步骤，而是让所有人理解：composer.lock 不是生成物，而是契约；它一旦被随意覆盖或跳过，环境一致性就从根子上瓦解了。哪怕只是临时删 lock 重装，也得同步通知队友——因为那意味着你单方面重写了团队共同遵守的依赖契约。
