composer why 不显示路径是因为它只查间接依赖，直接写在 composer.json 中的包会被视为直接依赖而忽略；应检查 composer.json、用 composer depends --all、或直接解析 vendor/composer/installed.json 确认来源。
composer why 为什么没显示依赖路径
执行 composer why vendor/package-name 却返回 “No dependencies exist for …” 并不意味着该包没被依赖，而是它可能被声明在 composer.json 的 require 或 require-dev 中——即直接依赖，而非间接引入。Composer 默认只展示“间接依赖链”，直接写死的包不会触发路径分析。
实操建议：
- 先确认该包是否出现在你项目的
composer.json里；如果是，它就是你主动加的，不是被谁拉进来的 - 若想查它是否被其他包“连带安装”，得用
composer why-not的反向思路：删掉它再composer install，看报错里谁缺它 -
composer show -t能列出完整依赖树，但信息密集，需配合grep筛选，例如：composer show -t | grep -A 5 -B 5 "package-name"
composer depends 查不到包名？大小写和命名空间问题
composer depends 是 Composer 2.2+ 引入的命令，功能等价于 why，但更严格。它默认只匹配完全一致的包名（含 vendor 名），且不支持模糊匹配或通配符。
常见错误现象：
- 输
composer depends monolog没结果 → 实际包名是monolog/monolog，必须写全 - 输
composer depends doctrine/orm报错 “Package not found” → 可能是该包被 require-dev 引入，而depends默认只查 require，需加--all参数 - 某些私有包或未启用的仓库中包，
depends不会扫描，除非已成功安装并记录在vendor/composer/installed.json
从 installed.json 手动追溯依赖来源
当命令行工具失效（比如 Composer 版本太旧、或依赖关系被修改过但未重装），最可靠的方式是查 vendor/composer/installed.json —— 这是 Composer 实际记录每个包安装原因的唯一权威来源。
关键字段说明：
-
name：包名 -
type：值为library/metapackage等，不影响依赖分析 -
require或require-dev字段不存在 → 它是直接依赖 - 若存在
dist和source，说明它是通过 packagist 下载的；若只有source且含url，可能是 VCS 包，依赖链可能断在本地配置
可快速定位：用 jq 查找（Linux/macOS）：
jq -r '.packages[] | select(.name == "vendor/package-name") | .require' vendor/composer/installed.json输出为空则为直接依赖；否则显示谁 require 了它。
dev-main 或分支版本导致 why 失效
如果某个包是以 "dev-main"、"dev-develop" 或 Git 分支形式 require 的，composer why 可能无法正确解析其来源，尤其当该分支未打 tag、也未在 packagist 同步元数据时。
此时表现是：
-
composer why返回空或报错 “Package not installed” -
composer show能看到包，但type是vcs，source.url指向 GitHub/GitLab - 该包的
composer.json若未声明autoload或require，Composer 甚至不会把它当作“可分析依赖”处理
解决办法只有两个：一是改用稳定版本（如 ^3.0）再试；二是直接打开它的 composer.json，人工检查它 require 了谁，再逐层往上推。
installed.json。一旦这个过程被跳过（比如用 git clone 替代 composer require）、或元数据不全（如分支包无 proper composer.json），所有自动化命令都会失准。真正稳的办法，永远是从 installed.json 出发，而不是依赖命令输出。
