快速定位冲突源需先运行 composer update --dry-run 查看具体冲突包，再结合报错末尾的“Root requirements”和“Found conflicting requirements”分析约束矛盾，辅以 composer depends --tree 和 composer show 定位依赖链。
composer install 报错 “Conclusion: don’t install xxx” 怎么快速定位冲突源
这是 Composer 依赖解析失败最典型的报错，本质是锁文件 composer.lock 里记录的版本与当前 composer.json 约束或已安装包不兼容。不是配置写错了，而是约束之间存在逻辑矛盾。
实操建议：
- 先运行
composer update --dry-run，它不改任何文件，但会完整走一遍依赖解析，输出具体哪两个包在“打架”——比如package-a v2.1要求symfony/console ^5.4，而package-b v3.0强制要求symfony/console ^6.0 - 看报错末尾的 “
Root requirements” 和 “Found conflicting requirements” 段落，重点盯住那些带!=、、<code>^的版本号，它们才是冲突起点 - 别急着删
composer.lock：它可能包含你手动 fix 过的历史妥协，直接删会导致其他环境行为突变
composer require 时提示 “Your requirements could not be resolved” 是因为什么
这个提示出现在添加新包阶段，说明新包的依赖树和现有项目无法共存。常见原因是新包最低要求的 PHP 版本、扩展或另一个包的版本，超出了你当前环境或已有依赖的上限。
实操建议：
- 检查
composer require vendor/name --no-update是否能成功：如果可以，说明只是 lock 文件没同步；接着跑composer update vendor/name单独更新它 - 用
composer show vendor/name查它所有已发布版本，再用composer show vendor/name x.y.z看特定版本的require字段，确认是否真需要你环境里没有的东西 - 注意
conflict字段：有些包在composer.json里明写了"conflict": {"laravel/framework": ">=10.0.0"}，这种硬性排斥不会在 require 阶段警告，只在 resolve 阶段爆错
为什么 composer update 不升级某些包，即使新版本明明满足版本约束
Composer 默认采用“最小变更”策略：只要现有已安装版本符合 composer.json 的约束（比如 "monolog/monolog": "^2.8"），就不会主动升级到 2.9 或 2.10，哪怕它们更稳定、有安全修复。
实操建议：
- 想强制升级某个包到最新兼容版？用
composer update vendor/name，不要加--with-dependencies，避免意外连带升级其他包 - 想升级整个依赖树到每个包的最新小版本（如 2.x → 2.latest）？用
composer update --minor-only（Composer 2.5+ 支持）；旧版本只能靠composer update+ 手动调composer.json中的约束范围 - 留意
prefer-stable: true设置：如果设为false，Composer 可能拉取dev-main这类不稳定分支，导致后续install在 CI 上失败
composer why-not package/version 输出一堆信息，怎么看懂关键路径
composer why-not 是排查“为什么不能装某版本”的核心命令，但它输出的是完整依赖链，容易淹没重点。
实操建议：
- 优先看第一行 “
There is no installed package depending on...” 后面的包名——如果这包根本没装，说明你当前环境压根没引入它，那冲突大概率来自composer.lock里残留的旧记录 - 从下往上读：输出是“从目标版本倒推谁拦住了它”，最后一层（最底部）才是真正的 blocker。比如最后出现
your-project requires php ^7.4，而你想装的包要求php >=8.0，那问题就清晰了 - 配合
composer depends --tree package/name看谁依赖了它，再结合composer show package/name查它的require，才能串起整条链
依赖冲突从来不是“哪个版本对”，而是“哪些约束同时成立时无解”。最常被忽略的是 PHP 版本、扩展启用状态、以及 composer.json 里被注释掉但仍在 lock 文件中生效的旧约束。每次 resolve 前，先 composer show --platform 确认真实环境，比反复重试更快。
