composer why 报“Package not found”是因为它只查询 composer.lock 中的依赖图，而非 vendor 目录；需确认包名拼写、是否存在 lock 文件、是否为 dev 依赖（加 --dev）、是否被 replace/provide 隐藏，或改用 composer depends 查使用方。
composer why 报错“Package not found”但明明装了
说明：composer why 只能查「直接或间接导致该包被安装」的顶层依赖，不能查已卸载或仅存在于 vendor/ 但未在 composer.lock 中记录的包。它查的是锁文件里的依赖图，不是文件系统快照。
实操建议：
- 先确认包名拼写完全一致（包括大小写、下划线/短横线），比如
monolog/monolog≠monolog/monolog-dev - 运行
composer show看是否真在当前 lock 文件中存在；若没有，说明它已被移除或从未被正式安装 - 如果包是通过
require --dev安装的，composer why默认不显示 dev-only 依赖链，需加--dev参数 - 某些插件（如
hirak/prestissimo）可能干扰依赖解析，可临时禁用：运行前加COMPOSER_DISABLE_XDEBUG=1
为什么 composer why monolog/monolog 显示空结果？
说明：这通常意味着 monolog/monolog 是作为「根依赖」被显式 require 的，而非被其他包拉进来的——它没有上游依赖者，只有下游使用者。
实操建议：
- 检查
composer.json的require或require-dev字段，看是否有直接条目 - 想查它被哪些包“用到”，得换命令：
composer depends monolog/monolog（注意是depends，不是why） -
composer why不支持通配符或模糊匹配，composer why monolog/*会失败 - 若项目用了
replace或provide声明（比如用psr/log-implementation替代具体实现），composer why不会追溯到提供方，只显示显式 require 的包
如何查清某个包是被谁的哪个版本拖进来的？
说明：composer why 默认只显示最短路径，且不展开版本约束细节。要定位具体触发版本，得结合锁文件和解析逻辑。
实操建议：
- 先运行
composer why <package>得到上游包名，再用composer show <upstream-package>查它的require字段，看对目标包的版本约束（如"monolog/monolog": "^2.0"） - 打开
composer.lock，搜索目标包，找到source或dist下的reference，再反查哪个上游包的依赖项最终匹配到了这个 commit/tag - 若多个路径并存，
composer why只返回一条（通常是字典序最小的路径），可用composer depends --tree <package>查完整依赖树（需 Composer 2.2+） - 注意
conflict和replace会影响实际安装结果，但composer why不反映这些干预逻辑
在 CI 或 Docker 构建中查依赖来源总失败
说明：CI 环境常跳过 composer install --no-dev 或清理了 vendor，导致 composer why 缺少上下文；Docker 构建层缓存也可能让 lock 文件与 vendor 不一致。
实操建议：
- 确保构建时保留
composer.lock并执行完整composer install（不要加--no-install或跳过 autoload 生成） - CI 脚本里查之前先跑
composer validate --no-check-publish，避免 lock 文件损坏导致解析中断 - Dockerfile 中，把
composer why放在COPY composer.* .和composer install之后，且不在多阶段构建的 builder 阶段外调用 - 某些私有仓库认证未配置好时，
composer why可能静默失败（无报错但无输出），可加-v参数看详细日志
事情说清了就结束。依赖溯源真正卡住的时候，往往不是命令不会用，而是没意识到 composer.lock 才是唯一权威来源，而 vendor/ 目录只是副产品。
