composer show 包名可查该包在composer.json中声明的直接依赖，仅显示require字段内容，不递归展开，未安装时需先执行composer install。
composer show 如何查某个包依赖了谁
直接看一个包的直接依赖，用 composer show 加包名最准。比如想查 monolog/monolog 依赖哪些包，运行：
composer show monolog/monolog
输出里 “requires” 那块就是它声明的直接依赖。注意：这里不展开递归，只显示 composer.json 中 require 字段写死的那些。
- 如果包没安装，
composer show会报错 —— 先composer install或确保已加载到锁文件 - 输出中的
dev-master或^2.0是版本约束，不是实际安装版本；要看真实装的是哪个，得配合--tree - 别用
composer depends反查“谁依赖我”，它只查当前项目 require 的包，不查require-dev或传递依赖
composer tree 怎么看完整引用链（含嵌套依赖）
composer tree 是查依赖深度最常用的命令，它从根项目出发，逐层展开所有传递依赖。默认只显示已安装的包，且按树形缩进呈现层级关系。
composer tree --format=tree laravel/framework
这样能看清 laravel/framework 被谁拉进来、它又带了哪些子依赖。关键点：
- 加
--no-dev可排除require-dev下的包，避免干扰主流程分析 - 不指定包名时，
composer tree默认从当前项目开始，顶层是your/project-name，容易漏掉“被间接引入但未显式 require”的包 - 某些包在不同路径下可能被多次引入（比如
symfony/polyfill被 5 个包各自 require），tree会重复列出，不代表装了多份 —— 实际共用同一份
为什么 composer why 和 composer why-not 返回结果让人困惑
composer why 查“为什么这个包被装上”，但它的判断依据是：是否出现在某条依赖路径的末端。不是“谁写了 require”，而是“谁最终导致它必须存在”。
例如执行 composer why psr/log，可能返回：
monolog/monolog 2.10.0 requires psr/log (^1.0.0 || ^2.0.0 || ^3.0.0)
但如果你自己也在 composer.json 里写了 "psr/log": "^3.0"，why 却可能不提你 —— 因为 Composer 认为它是被 monolog “带进来的”，你的声明被合并或覆盖了。
-
composer why-not更容易误读：它只检查“当前 lock 文件里没有该包”的原因，不预测安装后会不会冲突 - 若某包有多个 parent，
why默认只显示第一个匹配路径，不会列出全部 —— 想看全量？得手动翻composer.lock或用脚本解析 - 它对虚拟包（如
php,ext-curl）也返回结果，但那些不是“包”，别当成普通依赖去处理
依赖冲突时怎么快速定位真正卡点
当 composer update 报错说“can’t be installed”，错误信息末尾的 Root package 和 Found conflicting requirements 是关键。但真正卡点往往藏在中间某层。
推荐组合操作：
- 先跑
composer prohibits vendor/package:version，它比why更接近冲突现场，会列出所有阻止该版本安装的约束 - 再用
composer show --all看该包所有可用版本，确认你要的版本是否真的存在（有些包只维护dev-main，老版本早已 untag） - 如果涉及
php版本或扩展限制，composer check-platform-reqs必须跑一次 —— 很多人忘了本地 PHP 小版本和platform配置不一致
依赖链越深，composer.lock 里同一包出现的次数越多，手动比对越容易漏。真要理清，不如导出 JSON：composer show -f json | jq '.packages[] | select(.name=="xxx")'，比肉眼扫快得多。
