composer why 查看包被安装的原因，why-not 分析无法安装的原因。例如 why monolog/monolog 显示依赖来源和版本约束，why-not symfony/http-client 6.0 检测冲突，帮助排查依赖问题，支持 JSON 输出和别名命令，是调试 PHP 依赖的有力工具。
当你在使用 Composer 管理 PHP 项目依赖时，经常会遇到某些包被安装或不被安装的情况，而你可能不清楚背后的原因。这时候，Composer 提供了两个非常实用的命令： why 和 why-not，可以帮助你快速定位依赖关系的来源和冲突原因。
查看某个包为何被安装（composer why）
使用 composer why 命令可以查看某个包被引入项目的具体原因，包括是哪个包依赖了它，以及依赖的版本约束。
例如，你想知道 monolog/monolog 为什么出现在你的项目中：
composer why monolog/monolog
输出结果会显示：
- 哪些直接或间接依赖了这个包
- 每个依赖方指定的版本要求
- 该包当前安装的版本
这在排查“这个包是不是多余的”或“为什么装了这么老的版本”时特别有用。你可能会发现某个老旧的第三方包拖住了版本升级。
查看某个包为何无法安装（composer why-not）
当你尝试安装一个包却失败时，可以用 composer why-not 来分析原因。它会模拟安装并报告冲突点。
比如你想安装 symfony/http-client 的 6.0 版本但失败了：
composer why-not symfony/http-client 6.0
Composer 会告诉你：
- 当前项目中的哪个包与该版本存在版本冲突
- PHP 版本或其他平台依赖是否不满足
- 是否存在互斥的依赖规则
这个命令相当于一次“反向诊断”，帮助你理解为什么 Composer 拒绝安装某个组合。
实用技巧和注意事项
这两个命令支持缩写形式（如 why 和 why-not），也可以加上详细参数查看更完整的信息。
- 加上
-r json可以输出 JSON 格式，便于脚本处理 - 如果包名拼错或未安装，
why会提示“not found”，这时可先用composer show确认名称 -
why-not实际不会修改项目，只是分析可行性，可以放心使用
结合 composer depends（即 why 的别名）和 composer prohibits（why-not 的别名），你可以更灵活地调试依赖问题。
基本上就这些。合理使用 why 和 why-not，能大幅减少“为什么装了这个”或“为什么不让我升级”的困惑。依赖管理复杂时，它们就是你的排查利器。
