能，但需 composer 2.4+ 并启用实验特性：composer config experimental.show-depends true；更推荐用官方内置命令 composer why，无需配置、支持全版本、可追溯依赖路径。
composer depends 能不能直接查谁依赖了某个包？
能，但得看 Composer 版本和配置——composer depends 不是开箱即用的命令。Composer 2.3 及更早版本压根没有这个命令；2.4+ 才引入，且默认禁用，必须手动启用实验特性：composer config experimental.show-depends true。没这步，执行 composer depends monolog/monolog 就会报错：Command "depends" is not defined。
- 该配置只对当前项目生效，加
--global全局启用不推荐，容易污染其他项目 - 启用后，
composer depends vendor/package-name会列出所有在require（不含require-dev）中显式声明该包的已安装包 - 它不查“运行时
require”或自动加载类触发的隐式依赖，只看静态composer.json声明，所以结果最可靠
composer why 更稳、更常用，为什么？
composer why 是官方长期支持的内置命令，无需任何配置，所有 Composer 2.x 都可用，专为解决“谁把我拉进来的”这个问题设计。
- 执行
composer why psr/log，输出类似：laravel/framework v10.48.12 requires psr/log (^3.0)，直接告诉你哪个包、什么版本、用了什么约束 - 加
-t参数：composer why -t psr/log，能看到完整路径，比如laravel/framework → illuminate/console → symfony/console → psr/log - 如果某包只在
require-dev里被引用，默认不显示；想包含它，得加--dev标志 - 遇到版本冲突时，
why显示的是实际起作用的约束来源，比depends更贴近问题本质
查远程包（没装进项目）的依赖关系怎么办？
用 composer show --remote，它不碰本地 vendor/，而是直连 Packagist API 拉取元数据。
-
composer show --remote --tree monolog/monolog：查 monolog 的完整依赖树（含间接依赖） -
composer show --remote --direct monolog/monolog：只查它composer.json里require字段的一级依赖 - 注意大小写和 vendor 名必须完全匹配，
monolog错写成Monolog或漏掉monolog/都会失败 - 如果目标包已被弃用或私有，
--remote可能返回 404，此时只能去 Packagist 网页端查 “Dependents” 区域
导出、过滤、脚本化依赖分析的实用技巧
composer show --tree 和 composer why 输出都是纯文本，天然适合管道处理。
- 快速确认是否引入了某个底层包：
composer show --tree laravel/framework | grep "symfony/http-kernel" - 导出整个依赖树存档：
composer show --tree > deps-tree-$(date +%F).txt - 想结构化解析？配合
jq：composer show --format=json | jq '.packages[] | select(.name == "monolog/monolog")' - 注意：
composer show --tree在依赖冲突时展示的是 lock 文件里妥协后的版本，不是你写的约束——这时候看到guzzlehttp/guzzle v6.5.8，但你明明写了^7.0，说明有别的包卡住了它，得立刻接一句composer why guzzlehttp/guzzle和composer prohibits guzzlehttp/guzzle:7.*
真正麻烦的从来不是命令怎么打，而是当 why 显示三个不同包各自锁着 psr/log 的 ^1.0、^2.0、^3.0 时，你得自己判断哪个能松动、哪个是硬依赖——工具只给事实，决策还得人来拍板。
