用 composer depends vendor/package-name 可查谁直接依赖该包；若命令不存在则需升级 Composer 至 2.2+；它仅显示顶层直接依赖，不包含传递依赖或 require-dev 未启用的情况。
composer show --tree 怎么看某个包被谁依赖
直接用 composer show --tree vendor/package-name 会列出该包及其所有下游依赖，但不显示上游（即谁在 require 它）。想查“谁依赖了它”，得反向查——composer show 本身不支持原生反向依赖树，必须配合 composer depends（Composer 2.2+）或手动筛选。
composer depends vendor/package-name 查依赖来源
composer depends 是 Composer 2.2 引入的官方命令，专为查“被谁依赖”设计。执行后会列出所有直接 require 该包的顶层包（即 composer.json 中显式声明的包），不包括传递依赖。
- 如果提示
Command "depends" is not defined，说明 Composer 版本太低，先升级：composer self-update - 它只检查当前项目已安装的包，未安装的（如仅在
require-dev里但没启用）不会出现 - 对私有包或别名包（如
monolog/monolog别名为psr/log）不生效，只认实际安装的包名
没有 composer depends 时怎么手动查
老版本 Composer 或 CI 环境受限时，可用组合命令模拟：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer show -N | xargs -I {} sh -c 'echo {}; composer show {} | grep -q "vendor/package-name" && echo " └── depends on vendor/package-name"'
更可靠的做法是解析 composer.lock：
- 用
jq（需安装）：jq -r '.packages[] | select(.require."vendor/package-name") | .name' composer.lock - 纯 Bash（无 jq）：搜索 lock 文件中包含该包名且前面有
"require"的区块，再提取对应包名——但容易误匹配，慎用于生产环境 - 注意：
composer.lock中的require字段记录的是该包自身的依赖，不是它的上游；真正要找的是每个包的require是否含目标包，所以必须遍历.packages数组
为什么 vendor/package-name 在 depends 结果里没出现
常见原因不是命令错了，而是这个包根本没被当前项目“直接依赖”：
- 它只是某个依赖的子依赖（例如
laravel/frameworkrequiresymfony/console，你查symfony/console就不会出现在composer depends结果里） - 它被
require-dev声明，但当前运行环境没加载 dev 包（如COMPOSER_NO_DEV=1） - 它被
replace或provide替换掉了（比如用psr/log替换了monolog/monolog的日志接口） - 包名拼写错误，或用了别名（
composer show显示的是实际安装名，不是composer.json里写的别名）
最稳的办法永远是打开 composer.lock 搜 "vendor/package-name"，确认它是否真的存在、在哪一级被引入。
