composer depends命令不存在，官方从未提供；应使用composer why（查反向依赖）、composer show --tree（查正向依赖树）或composer-unused插件（查未使用包）。
composer depends 命令本身并不存在 —— 这是很多人在排查依赖关系时踩的第一个坑。Composer 官方 CLI 没有 depends 子命令，真正可用的是 composer show --tree 和 composer depends 的替代方案：第三方插件或原生命令组合。
为什么找不到 composer depends？
Composer 核心不提供反向依赖查询（即“谁依赖了这个包”），因为这需要遍历所有已安装包的 composer.json 中的 require 字段，而 Composer 默认只维护正向依赖图。官方认为该操作属于分析/审计场景，非日常安装流程必需。
常见错误现象：
- 执行
composer depends monolog/monolog报错：Command "depends" is not defined. - 误以为它是 2.x+ 新增功能，实则至今（v2.7.x）仍未纳入核心
用 composer show --tree 看清当前项目的依赖链
这是最轻量、无需额外安装的方案，适合快速确认某个包是否被直接或间接引入，以及它处于哪一层。
- 运行
composer show --tree vendor/package-name（如composer show --tree guzzlehttp/guzzle）会打印出从根项目开始、向下展开的完整调用路径 - 注意：只显示“当前项目能访问到的路径”，不反映其他未启用的 require-dev 或条件加载分支
- 若包未出现在树中，说明它未被当前
composer.lock解析生效 —— 可能是被replace、conflict排除，或仅存在于require-dev但未在当前环境启用
用 composer-unused 插件查“未被使用的依赖”
虽然不是严格意义上的 depends，但它通过静态分析代码引用 + 对比 composer.json，能帮你发现哪些包声明了却没人用 —— 这往往是依赖混乱的起点。
- 安装：
composer global require composer-unused/composer-unused - 运行：
composer-unused（默认扫描src/和tests/） - 输出类似：
Package "symfony/var-dumper" is required but not used. - 注意：它不告诉你“谁依赖了 A”，但能暴露 A 是否冗余 —— 如果 A 是被 B 间接拉进来的，而你又删掉了 B，A 就可能变成孤儿
用 composer why 和 composer why-not 定位冲突根源
这两个是 Composer 内置命令，实际解决大部分“依赖卡住”问题的主力。
-
composer why vendor/package：列出直接或间接 require 该包的所有上游包（含版本约束），例如：laravel/framework 10.48.5 requires symfony/console (^6.2) -
composer why-not vendor/package:version：当你想升级却失败时，它会指出哪个已安装包的约束阻止了升级，比如：myapp/mylib v1.2.0 requires php ^8.0而你试图装phpunit/phpunit 10.5（需 PHP 8.1+） - 二者都基于 lock 文件实时计算，结果可靠；但不会显示 require-dev 中的间接依赖，除非你加
--with-dependencies
真正做模块级依赖审计时，别指望一个命令扫清全局。关键在于：先用 composer why 锁定触发点，再用 composer show --tree 验证路径，最后靠 composer-unused 清理死角 —— 手动串联才是目前最稳的路径。另外，composer.lock 文件本身是权威来源，直接打开看 packages 和 packages-dev 的 require 字段，有时比任何命令都快。
