执行 composer update --dry-run -v，通过详细日志定位冲突源：末尾会明确指出“a 需要 b ^2.0，而 c 要求 b”等具体约束矛盾。
composer install 报错 “Conclusion: don’t install xxx” 怎么快速定位冲突源
这是 Composer 依赖解析失败最典型的提示，本质是锁文件 composer.lock 里记录的版本与当前 composer.json 约束或已安装包不兼容。别急着删 lock 文件重装——先看它到底卡在哪。
执行 composer update --dry-run -v，加上 -v（verbose）会输出完整依赖图和回溯路径，关键信息在最后几行：它会明确写出「因为 A 需要 B ^2.0，而 C 要求 B
- 优先检查报错中反复出现的包名，比如
monolog/monolog或phpunit/phpunit，它们常是冲突枢纽 - 注意 PHP 版本约束是否被忽略：
"php": "^8.1"写在composer.json顶层，但某个依赖只支持 7.4，Composer 就会死在这里 - 如果用了
require-dev里的测试工具（如phpstan/phpstan），它们可能悄悄拉低主依赖的版本上限
require 和 require-dev 的依赖混在一起导致升级失败
很多人把开发期工具（如 phpunit、larastan）和运行时依赖（如 guzzlehttp/guzzle）全塞进 require，结果一升级就崩。Composer 不区分环境，所有 require 条目参与统一版本求解。
正确做法是严格分层：
- 运行时必须的包（没它项目根本跑不起来）→ 放
require - 仅本地开发、CI 或调试用的包（比如
barryvdh/laravel-debugbar）→ 放require-dev - 如果某个包在 dev 和 prod 都需要，但版本要求不同（比如 prod 用 v1，dev 用 v2），那就不能共存，得用
conflict显式声明互斥
执行 composer update --no-dev 可临时绕过 dev 依赖验证，快速确认是不是它们拖了后腿。
composer update 升级范围失控，误升了不该动的核心包
composer update 默认更新所有包，哪怕你只想修一个安全补丁，也可能把 symfony/http-kernel 从 v6.2 升到 v6.4，结果触发一堆 BC break。这不是 Composer 的 bug，是你没管住命令粒度。
精准控制升级范围才是日常操作：
- 只更新某一个包：
composer update vendor/package-name（注意不是vendor/package-name:version） - 锁定主版本，避免跨大版本跳跃：
composer update "monolog/monolog:^2.0"（引号防 shell 解析错误） - 想保留现有版本，只更新次要版本（如 3.1 → 3.8，但不升到 4.x）：
composer update --with-dependencies配合^3.0约束更安全
顺带一提：composer outdated 能列出所有可更新包及当前/最新版本，比盲猜靠谱得多。
锁文件被忽略或手动修改后引发隐性冲突
composer.lock 不是日志，是依赖快照。只要它存在，composer install 就完全按它还原，哪怕 composer.json 里写的约束更宽。很多人删 lock 文件、改完 json 再 install，以为“重来一遍”就干净了——其实只是把问题延后。
真正要做的，是让 lock 文件和 json 保持因果一致：
- 团队协作时，
composer.lock必须提交进 Git，否则每人 install 出来的依赖版本可能不同 - 不要手动编辑
composer.lock，哪怕只是改个 hash——Composer 有自己校验机制，改完会导致install失败或跳过某些包 - 如果发现 lock 文件里某个包版本明显“老得不合理”，先查
composer show vendor/package看它实际能装什么版本，再反推是哪个依赖在压制它
最麻烦的情况是多个私有仓库 + 自定义 repositories 配置，这时候 composer why-not vendor/package:version 比任何文档都管用。
