composer why 命令用于查看某包被安装的原因,例如执行 composer why symfony/var-dumper 可知 laravel/framework 依赖它;通过 composer why monolog/monolog 能发现旧版本被 some/package 锁定;使用 --tree 参数可展示依赖层级,如间接引入 phpunit/phpunit 的路径;还可判断如 guzzlehttp/guzzle 是否可安全移除,从而理清依赖关系,避免升级或删除时出错。

当你在使用 Composer 管理 PHP 项目依赖时,可能会遇到某些包被安装但不清楚是谁引入的情况。composer why 命令就是用来解决这类问题的——它能告诉你某个包为什么会被安装,也就是查看该包的依赖来源。
运行以下命令可以查看指定包是被谁依赖的:
composer why vendor/package例如,你想知道 symfony/var-dumper 是怎么进入项目的,可以执行:
composer why symfony/var-dumper输出结果会显示是哪个包要求了它,以及对应的版本约束。比如可能看到:
laravel/framework requires symfony/var-dumper (^5.0 || ^6.0)这说明 Laravel 框架需要这个组件,所以它被自动安装了。
有时候你发现某个包的版本比预期低,可能是被其他依赖限制了。composer why 也能帮你定位这个问题。
比如你希望用 monolog/monolog 2.x,但实际装的是 1.x,可以这样查:
composer why monolog/monolog输出中如果看到某包锁定了旧版本,如:
some/package requires monolog/monolog ^1.0那只要这个包不升级,你就无法使用 2.x 版本。
加上 --tree 参数可以展示依赖的层级关系:
composer why --tree vendor/package例如:
composer why --tree phpunit/phpunit输出可能类似:
my/project这样你能清楚看到是从项目本身通过 dev-utils 间接引入了 PHPUnit。
有些包可能只是“传递性依赖”存在,实际上没人主动使用。你可以用 composer why 判断是否可以安全移除。
比如你考虑删除 guzzlehttp/guzzle,先运行:
composer why guzzlehttp/guzzle如果输出显示没有直接依赖,只有几个次要工具引用它,而且那些工具支持其他 HTTP 客户端,那你就可以考虑替换或移除。
基本上就这些。合理使用 composer why 能帮你理清复杂的依赖网,避免盲目升级或删除包带来的问题。
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号