composer depends 是查“谁依赖了我”的唯一可靠命令，它基于 vendor/composer/installed.json 和 composer.lock 计算真实依赖链，结果可信、快速、离线，需在项目根目录执行且仅反映已安装状态。
composer depends 是查“谁依赖了我”的唯一可靠命令
想快速知道 monolog/monolog 是被 laravel/framework 还是 symfony/console 拉进来的？直接跑 composer depends monolog/monolog。它不是猜的，而是读 vendor/composer/installed.json 和 composer.lock 算出来的实际依赖链，结果可信、速度快、不依赖网络。
- 必须在项目根目录执行，否则报错“Could not find package”
- 如果包没装上（比如你删了
vendor但没composer install），命令会失败——它只看已安装状态，不查 Packagist 元数据 - 输出里带箭头的层级（如
your/project → guzzlehttp/guzzle → psr/http-client）表示间接路径，不是所有行都是直接 require
加 –tree 让依赖路径一目了然
composer depends 默认平铺列出包名，但看不出嵌套关系。加 --tree 就能还原真实引用链，尤其适合排查版本冲突：比如两个不同分支都引了 phpunit/phpunit，但一个要 v9，一个要 v10，树状输出能立刻定位分叉点。
- 示例：
composer depends symfony/yaml --tree可能输出：your/project<br>└── laravel/framework<br> └── symfony/yaml - 注意：它不会显示 dev 依赖（除非你手动加
--dev），而很多测试工具链藏在 dev 里，漏掉可能误判 - 如果输出过长，用
composer depends xxx --tree | head -20先看顶层，避免滚动失焦
别把 composer show –tree 和 composer depends 搞混
composer show --tree monolog/monolog 查的是“这个包自己依赖谁”，是向下查；composer depends monolog/monolog 查的是“谁依赖了它”，是向上查。方向反了，结论就完全相反。
- 常见错误：看到
monolog/monolog在composer show --tree里出现在某包下面，就以为是那个包主动 require 的——其实可能是它的子依赖引入的，真正源头得靠depends -
composer show --tree无法跨包追溯，比如 A→B→C，你想知道谁引了 C，show --tree A会显示 C，但不会告诉你 B 是中间层；depends C才会明确列出 A 和 B - 想验证某个包是不是冗余？先
composer depends xxx，如果返回空，再结合composer why-not xxx看是否被禁止安装，比盲删安全得多
依赖来源不在 vendor 里？那 depends 就查不到
composer depends 只分析当前 vendor/ 目录的真实安装结构。如果你用 path 仓库、repositories 本地源，或者包被 replace 或 provide 掉了，它可能显示“未找到”或漏掉某些路径。
- 私有包走
path类型仓库时，composer depends仍能识别，但要求该路径下有合法composer.json且已成功 install - 被
"replace": {"psr/log": "*"}的包，不会出现在depends psr/log结果中——因为 Composer 认为它已被替代，逻辑上“不存在” - 需要全局视角？去 Packagist 的 Dependents 页面 看公开引用，但那是静态声明，不反映你项目里的实际解析结果
依赖关系不是静态快照，而是 Composer 解析器在特定 lock 文件、PHP 版本、平台配置下算出的结果。同一行 composer depends 命令，在 CI 环境和本地执行，可能因 platform 配置不同而输出不一致。
