composer why 查不到包是因为它仅在 composer.lock 存在且包已安装时有效；常见原因包括未安装、--no-dev 环境、provide 虚拟提供、或未执行 install/update。
composer why 为什么查不到我的包？
composer why 不是万能探针，它只在 composer.lock 已存在且目标包确实被安装进 vendor 的前提下才有效。常见“查不到”的真实原因有：
-
composer show vendor/package-name返回空 —— 说明该包根本没装上，why自然无从谈起 - 包是用
composer require --dev装的，但当前执行环境启用了--no-dev（比如生产部署时） - 包被其他包用
"provide": {"psr/log-implementation": "*"}声明“虚拟提供”，它本身不落地，why psr/log-implementation必然失败 - 项目还没跑过
composer install或composer update，composer.lock缺失或过期
验证是否真装了：先运行 composer show 看列表，或 ls vendor/vendor-name/ 确认目录是否存在。
怎么看到完整的依赖链，而不仅是“谁直接 require 我”？
composer why 默认只显示最短路径（即离项目根最近的一条引用），容易误判源头。真正要定位“谁在 composer.json 里写了它”，必须加 --tree：
-
composer why --tree monolog/monolog会输出类似：my-project └── laravel/framework ^10.0 └── monolog/monolog ^2.0这说明：你没手动 requiremonolog/monolog，是laravel/framework拉进来的 若路径在某一层中断（比如停在
foo/bar就没了），大概率是它用了replace或provide声明替代了目标包想排除开发依赖干扰，加
--no-dev；想看具体版本约束条件，加-v
想查“我被谁依赖”，不是“我依赖谁”，该用哪个命令？
composer why 和 composer depends 功能高度重叠，但语义和默认行为不同：
-
composer depends vendor/package是更直白的“影响范围扫描”：列出所有直接/间接依赖该包的已安装包，适合评估移除风险 -
composer why vendor/package更侧重“安装原因”，输出带解释性文字（如 “required by my-project”），可读性略强 - Composer 2.2+ 开始，
depends支持-t（tree）、--recursive等参数，灵活性更高；老版本只能靠why --tree替代
注意：depends 查的是“谁依赖我”，不是“我依赖谁”——别和 composer show --tree 混淆。
排查“明明有新版却升不了”，why-not 比翻配置快得多
当 composer require vendor/package:3.0 报错，或者 composer update 死活不升级某个包，别急着改 composer.json。先用：
-
composer why-not vendor/package:3.0
它不看已装版本，而是分析整个依赖图中所有现存约束，指出哪条规则锁死了版本
常见结果包括：
-
symfony/console (locked at 5.4.39)要求psr/log ^1.0，而vendor/package:3.0要求psr/log ^3.0→ 冲突 - 某个包声明
"conflict": {"vendor/package": ">=2.0"}，直接封杀
这个命令查的是逻辑约束，不是物理安装状态，所以即使本地没装 vendor/package，只要别人写了不兼容的 require 或 conflict，它就会报出来。
依赖链不是线性的树，而是带环、带替换、带虚拟声明的有向图。想靠眼睛扫 composer.json 找源头，基本等于盲人摸象。工具用对了，问题就解决了一半。
