PHP环境中的依赖冲突解决：使用composer why分析包依赖关系-php教程-PHP中文网

composer why 用于查“谁显式要求该包”，只显示直接在 require 或 require-dev 中声明目标包的上游包及其精确版本约束，为空则说明无显式引用；真正定位升级阻断需用 composer why-not 包名:版本号。

php环境中的依赖冲突解决：使用composer why分析包依赖关系

解决 PHP 项目中的依赖冲突，关键不是盲目升级或删包，而是先搞清“谁在卡住它”。composer why 是定位冲突源头最直接的命令——它不查你用了什么，而是查“谁把你拉进来的”，帮你快速识别显式声明了冲突包的上游依赖。

运行 composer why vendor/package-name（如 composer why monolog/monolog），它只显示当前 composer.lock 中直接在 require 或 require-dev 字段里写了该包的上游包。输出类似：

注意每行末尾的版本约束，它来自那个上游包自己的 composer.json，不是你项目当前装的版本。如果两个约束互斥（比如一个要 ^1.25，另一个要 ^2.0），这就是冲突的显性信号。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

如果 composer why 报 Package not found 或返回空，别急着换命令，先检查：

包名是否完全准确：必须小写、带斜杠，如 guzzlehttp/guzzle，不能是 GuzzleHttp/Guzzle 或漏掉 /
该包是否真在 vendor/ 下存在，且已记录在 composer.lock 中（可先运行 composer show 确认）
它是不是仅通过 require-dev 安装的？没加 --dev 参数时，默认不查开发依赖：composer why --dev phpunit/phpunit

composer why 默认只显示第一层来源，容易误判。加 --tree 才能看到从根项目开始的实际安装链：

composer why --tree monolog/monolog 可能输出：

my-project<br>
  └── laravel/framework ^10.0<br>
    └── monolog/monolog ^2.0

这说明你没手动 require 它，是 Laravel 拉进来的；若路径中断在某一层（比如停在 psr/log 就没了），大概率是被 provide 或 replace 隐藏了
想排除开发包干扰，加 --no-dev；想看到具体约束条件，加 -v

当报错是 Conclusion: don't install thinkphp/framework v6.0.10，立刻运行：

composer why-not thinkphp/framework:6.0.10
它会模拟安装过程，告诉你在哪一层被阻断：可能是你根 composer.json 的原始需求、某个已装包的 conflict 字段（如 "conflict": {"thinkphp/framework": ">=6.0"}）、或 PHP 扩展缺失（如 ext-intl 未启用）
输出中带 requires php 的行要重点检查——很多 TP6 冲突实际是 PHP 8.0+ 和某扩展包的 php ^7.4 矛盾