Composer why 怎样查出依赖是被谁引入

Composer 遇到依赖冲突、包体变大或某个库被意外装进来时，最先要回答的通常不是“怎么删掉它”，而是“谁把它引入了项目”。Composer 的 depends 命令别名就是 why，它会从当前项目的依赖关系中反查某个包的依赖者；需要看完整链路时，再加 --tree 或 -t。官方地址：https://getcomposer.org/。

先用 composer why 包名 找“谁依赖它”，再用 composer why 包名 -t 展开递归关系。如果问题变成“为什么不能安装某个版本”，就改用 composer why-not 包名 版本；这两组命令回答的是不同问题。

• why/depends：追溯目标包的引入者。
• --tree/-t：把依赖者继续展开成树形关系。
• why-not/prohibits：解释目标版本被哪些约束或包阻止。

先用 why 找到目标包的引入者

我排查 Composer 项目时，会先从报错里提取准确的包名，例如 psr/log，然后在包含 composer.json 和 composer.lock 的项目根目录执行查询。这里的包名必须写成 Composer 的标准 vendor/package 形式；只写一个模糊的库名，得到的结果就很难和依赖文件对应。

# 在项目根目录反查：哪些包依赖目标包
composer why psr/log

# why 是 depends 的别名；需要团队脚本统一时可以固定其中一种写法
composer depends psr/log

# 只查询某个约束范围时，把版本约束放在包名后面
composer why psr/log "^3.0"

官方命令说明中，why 输出的是“其他哪些包依赖这个目标包”。它不是包详情查询，也不会自动告诉你某个版本为什么无法解析。看到一行关系后，先判断左侧包是根项目的直接要求，还是另一个依赖的间接要求；这个判断决定了后续应该修改 composer.json，还是先处理上游包的版本约束。

用 tree 分清直接依赖和间接依赖

只看一行 why 结果，遇到多层依赖时容易误判。此时加上 --tree（短选项为 -t），Composer 会递归展示关系。--recursive（短选项为 -r）也可以表达递归查询；实际排查时我更偏向 -t，因为树形层级更适合和团队一起讨论。

# 展开目标包的递归依赖关系
composer why psr/log --tree

# 等价的短写法，适合临时排查
composer why psr/log -t

# 只保留递归查询含义，不要求树形展示时使用 -r
composer why psr/log --recursive

树形结果里的第一层通常更接近直接依赖，下一层则可能是间接依赖。示例关系可以抽象成“应用依赖 A，A 依赖 B，B 依赖目标包”。这时删除目标包通常没有意义：只要 A 或 B 仍然要求它，下一次解析仍可能把它带回来。更稳妥的动作是回到真正的直接依赖，检查它的约束是否允许升级、替换或移除。

还要留意查询上下文。Composer 官方说明指出，安装时会结合项目声明和锁文件处理依赖；因此依赖树反映的是当前项目状态。你修改了 composer.json 但尚未重新解析，树形关系不一定就是下一次更新后的最终结果，排查记录里应写清查询时是否保留了现有 composer.lock。

把 why 和 why-not 分开

“谁引入了这个包”和“为什么目标版本装不上”是两种不同的问题。前者继续用 why；后者用 why-not，它是 prohibits 的别名，用来定位阻止指定版本的依赖约束。

# 查询某个包由谁引入：关注来源关系
composer why symfony/console

# 查询目标版本为什么不能安装：关注阻止它的约束
composer why-not symfony/console 7.0

# prohibits 是 why-not 的同义命令；二选一即可
composer prohibits symfony/console 7.0

如果目标是升级一个间接依赖，先用 why-not 找出约束来源，再决定是否需要对直接依赖执行更新。不要把 --ignore-platform-reqs 当作解决依赖关系的办法：它只会忽略指定的平台要求，不能改变包之间的版本约束，也不能替代对依赖树的判断。

一份可复查的排查清单

我通常把一次排查收敛成四条记录：第一，保存目标包的完整名称；第二，记录执行的是 why 还是 why-not；第三，若用了 -t，标明观察到的直接依赖和间接依赖层级；第四，修改依赖后重新查看 composer.json、composer.lock 与查询结果是否一致。

这样做的好处是，依赖关系变化时可以解释“为什么这个包还在”，而不是反复删除 vendor 目录碰运气。若结果仍然异常，再运行官方建议的 composer diagnose 检查环境问题；环境检查与依赖来源查询是两条线，不要用其中一条代替另一条。

相关问题

Composer why 查不到目标包怎么办？

先确认命令是在项目根目录执行，包名是否完整，以及目标包是否真的出现在当前依赖解析结果中。若只是想查某个可用版本，先用准确的包名和版本约束重试。

Composer why 和 why-not 能连着用吗？

可以，但顺序取决于问题：先确认来源用 why，再针对升级目标用 why-not。它们的输出维度不同，不应把一条命令的结果当成另一条命令的结论。