Composer.lock冲突与依赖逻辑冲突本质不同：前者是Git文件快照不一致，应通过checkout恢复lock后install解决；后者是composer.json约束互斥，须用composer why-not定位阻断链并配合--with-dependencies精准更新。
直接删掉 composer.lock 文件再跑 composer install 不仅不能解决问题，反而大概率让环境更不一致——因为 composer.lock 冲突和依赖逻辑冲突是两回事，处理方式完全不同。
先分清是 lock 文件 Git 冲突，还是 Composer 依赖解析失败
Git 合并时提示 composer.lock 有冲突，只是文件内容不一致；而运行 composer update 或 composer install 报 “don’t install xxx” 才是真正的依赖逻辑冲突。两者必须分开处理：
- Git 冲突：说明两个分支各自生成了不同的 lock 快照，但未必代表依赖不可共存
- 解析失败：
composer update卡住或报错，说明composer.json中的约束存在互斥，SAT 求解器无解 - 常见混淆：CI 构建失败显示 “Your lock file does not contain a compatible set of packages”，这其实是
composer.json已被修改、但composer.lock没同步更新导致的校验失败，不是 Git 冲突本身
Git 合并时 composer.lock 冲突了，别手动改
composer.lock 是完整依赖图的哈希快照，不是配置文件。手动删几行、保留“这边的版本”或“那边的 hash”，会导致后续 composer install 校验失败甚至类加载异常。
- 确认
composer.json无冲突（git status看一眼），这是前提 - 执行
git checkout --ours composer.lock或git checkout --theirs composer.lock，任选其一还原为干净状态 - 删掉
vendor/目录（确保无残留） - 运行
composer install—— 它会基于当前composer.json和刚恢复的 lock 重新校验并生成新 lock - 如果提示校验失败，说明
composer.json已被他人提交变更，先git pull，再重试
composer update 报 “don’t install” 是真冲突，用 why-not 定位源头
错误信息里那句 Conclusion: don't install laravel/framework v10.32.0 是结果，不是原因。真正要查的是谁在拦路。
- 运行
composer why-not laravel/framework:v10.32.0（必须带完整版本号，如v10.32.0，不能只写^10.0） - 输出是从底往上读的反向链：最后一行是你
composer.json的根声明，最上面一行才是最上游的硬性封杀者 - 输出为空？优先检查
require-dev—— 很多冲突来自phpunit/phpunit或orchestra/testbench间接锁死旧版symfony/console - 加
--dry-run验证：例如composer require guzzlehttp/guzzle:^7.5 --dry-run，不改任何文件就能看到是否可解
升级或降级单个包时，必须加 --with-dependencies
不加这个参数，Composer 默认拒绝更新其子依赖，哪怕新版本根本跑不起来。比如只更新 monolog/monolog 到 v3，但它的直系依赖 psr/log 还卡在 v1，就会导致运行时报 Class not found。
- 正确命令：
composer update monolog/monolog --with-dependencies - 错误写法：
composer update "monolog/monolog:^3"（引号 + ^ 会让 Composer 自行找“最新兼容版”，不是你要的 3.0.0） - 升级后立刻
git diff composer.lock，只接受目标包及其直系依赖变更；如果波及十几个包，说明约束没控住，得回退 - 注意
conflict字段是硬规则：哪怕你没require某个包，只要其他已装包间接拉进来，也会触发冲突
最常被忽略的一点：require-dev 从 Composer 1.7 起全程参与依赖解析，它不是“只在本地有用”。很多看似莫名其妙的冲突，源头都在 phpunit/phpunit 或 mockery/mockery 的隐式约束里。
