composer why 的核心作用是查清某个包被安装的直接上游依赖。它只显示当前已安装版本的直接引用者，不展开间接依赖链，也不涵盖 dev 依赖、私有源包或 replace 场景，需结合 composer depends、composer show 和 composer.lock 交叉分析版本来源。
composer why 的核心作用很直接：查清某个包为什么被安装进项目。它不告诉你“怎么装”，而是回答“谁拉你进来的”。如果你看到 vendor/ 里有个包，但完全没在 composer.json 里手动 require 过，又不确定是不是间接依赖、安全补丁或历史残留——这时候 composer why 就是唯一靠谱的溯源工具。
查某个包被谁依赖（基础用法）
最常用场景：发现项目里有 symfony/polyfill-mbstring，但自己没写过 require，想知道谁带进来的。
执行：
composer why symfony/polyfill-mbstring
输出类似：
laravel/framework v10.48.12 requires symfony/polyfill-mbstring (^1.28)
说明：这个 polyfill 是 laravel/framework 显式声明需要的。注意它只显示**直接上游依赖**，不会展开到 laravel/framework 自己又被谁 require —— 想继续追，得手动再跑一次 composer why laravel/framework。
- 如果包名拼错或未安装，会报
Package not found - 包名必须完整，比如
monolog/monolog不能简写成monolog - 支持带版本号查询，如
composer why monolog/monolog:2.9.1，但仅当该精确版本实际存在于vendor/中才有效
查某个包被谁以什么版本依赖（带版本解析）
有时候同一个包在 composer.lock 里存在多个版本（比如因冲突降级），composer why 默认只显示当前实际安装的版本来源。想确认“为什么装的是 1.2.3 而不是 1.3.0？”就得结合 --tree 或锁文件分析。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
执行：
composer why --tree symfony/console
输出会展示层级关系：
myapp/myproject
└── laravel/framework v10.48.12
└── symfony/console v6.3.4
-
--tree不会自动展开所有路径，只显示一条解析链（通常是最高优先级那条） - 若一个包被多个包依赖，
composer why默认只返回第一个匹配项（按composer.lock顺序），无法列出全部上游 - 真正要查“所有引用者”，得用
composer depends --tree（Composer 2.5+），但注意它查的是“谁依赖我”，语义和why相反
为什么 composer why 查不到某些包？
常见误判：运行 composer why foo/bar 返回空或报错，就以为“没人依赖它”，其实可能只是没走标准依赖链。
- 该包是通过
composer require --dev安装的，但当前运行在生产环境（COMPOSER_DEV=0或--no-dev）下，why默认不查 dev-only 包 - 包是通过
repositories配置的私有源或package类型手动定义的，不属于正常 require 关系，why无法追踪 - 包被
replace规则覆盖了（比如psr/log被monolog/monologreplace），此时查psr/log会失败，因为实际安装的是monolog/monolog - 项目用了
composer install --ignore-platform-reqs或强制版本锁定，导致依赖解析结果与composer.json声明不一致，why仍按 lock 文件真实状态回答，但人容易误解为“逻辑矛盾”
配合 composer show 和锁文件交叉验证
composer why 给的是“谁拉你进来”，但不解释“为什么拉这个版本”。要定位版本冲突或意外降级，必须看 composer.lock 里的 requires 和 packages 字段，再比对 composer show -t 的完整依赖树。
例如：发现 guzzlehttp/guzzle 装的是 7.8.1，但期望是 8.x。先跑：
composer why guzzlehttp/guzzle→ 得到上游是
aws/aws-sdk-php；再跑：composer show aws/aws-sdk-php | grep guzzle→ 看它声明的
require 范围；最后打开 composer.lock，搜 aws/aws-sdk-php 的 version 和它 requires 下的 guzzlehttp/guzzle 约束 —— 这三步合起来才能判断是上游限制太死，还是本地 composer.json 冲突压低了版本。
真正的难点从来不在命令怎么敲，而在于理解 Composer 解析器如何权衡所有 require、conflict、provide 和平台配置。一个 why 输出只是一张快照，背后是整棵树的约束求解过程。
