composer depends 默认只检查当前项目 require 区块的直接依赖，忽略 require-dev 和间接依赖；需加 --dev、--recursive 等参数才能查开发依赖和向上追溯，且包名须完全匹配（如 monolog/monolog）。
直接用 composer depends 就能查出谁依赖了某个包，但默认不显示版本约束、不递归、不区分开发依赖——多数人第一次跑完以为没结果，其实是被默认行为“骗”了。
为什么 composer depends 看不到任何输出？
这是最常踩的坑：命令默认只检查当前项目 require 区块里的包，忽略 require-dev，也不查已安装但未在 composer.json 显式声明的间接依赖。
- 加
--dev才能查开发依赖（比如phpunit/phpunit） - 加
--recursive才会向上追溯到父级依赖（例如查symfony/polyfill-php80谁在用它） - 包名必须完全匹配，
monolog不等于monolog/monolog，后者才是正确写法
composer depends 的三个关键参数组合
实际排查时，几乎总是要叠加使用。比如想定位哪个包把旧版 guzzlehttp/psr7 拖进来的：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer depends guzzlehttp/psr7 --dev --recursive
-
--tree会以缩进形式展示依赖链，但只对直接依赖有效，递归时不可靠 -
--format=json输出结构化数据，适合脚本解析（注意：JSON 不包含 dev 依赖，除非显式加--dev） - 不加任何参数时，它其实只查当前项目的
composer.json直接依赖项，不是“整个 vendor”
替代方案：当 composer depends 查不到时怎么办？
有些情况它确实无能为力，比如包是通过插件、脚本或动态加载引入的，或者 Composer 缓存没更新：
- 先运行
composer update --lock确保composer.lock是最新状态 - 手动翻
composer.lock，搜索目标包名，看packages和packages-dev下的require字段 - 用
composer show -t查当前项目完整依赖树，然后grep定向筛选（虽然慢，但最可靠）
真正麻烦的不是命令不会用，而是误以为 composer depends 能看到所有依赖路径——它只看 Composer 解析出的静态依赖图，不处理运行时 require 或插件注册的依赖。
