composer的depends和prohibits命令均基于composer.lock文件解析，非实时读取composer.json；包名须严格匹配vendor/name格式，全局包、未声明包或平台限制均不可查。
composer depends 查不到包？先确认包名是否精确匹配
执行 composer depends vendor/package-name 时返回“Package not found”，大概率不是命令错了，而是包名没写对——Composer 默认只认 vendor/name 格式，不接受别名、缩写或带 .git 后缀的 URL。比如你想查谁依赖了 monolog/monolog，写成 monolog 或 monolog/monolog.git 都会失败。
实操建议：
- 用
composer show列出已安装包，复制完整vendor/name（注意大小写） - 如果目标包是
dev-main或1.x-dev这类开发版本，depends仍能查，但前提是它已被当前项目解析并写入composer.lock - 全局安装的包（如
phpunit/phpunit通过composer global）不会出现在项目依赖树里，depends对它们无效
prohibits 命令为什么总显示“no matching packages”？
composer prohibits package/name 的作用是反向排查冲突源：找出哪些已装包的版本约束，直接或间接阻止你安装指定包。但它不扫描“未来可能装的包”，只看当前 composer.lock 和 composer.json 中已声明的约束。
常见卡点：
- 目标包本身没在
require或require-dev里声明 →prohibits找不到上下文，自然无输出 - 冲突来自嵌套依赖的版本范围（比如 A 要求
symfony/console:^5.4，B 要求symfony/console:^6.0），但prohibits只报最上层直接冲突项，深层传递链需配合composer why-not看 - PHP 版本或扩展限制（如
ext-gd缺失）不会被prohibits捕获，那是composer check-platform-reqs的事
依赖树太深看不清？用 –tree 和 –no-dev 控制输出粒度
composer depends 默认只显示一级直接依赖者，而 --tree 才会展开完整层级。但盲目加 --tree 容易刷屏，尤其当某个基础包（如 psr/log）被几十个包间接引用时。
实用组合：
- 先跑
composer depends vendor/package --tree快速定位入口点 - 加上
--no-dev排除require-dev里的测试工具链（如phpunit、mockery），避免干扰主业务依赖分析 - 如果输出过长，用
composer depends vendor/package --tree | head -n 50（linux/macos）或composer depends vendor/package --tree | more（windows）分页看 -
--tree不影响prohibits，后者无此参数，强行加会报错
为什么本地改了 composer.json 却查不到新依赖关系？
depends 和 prohibits 全部基于当前 composer.lock 的解析结果，不是实时读取 composer.json。你刚在 require 里加了一行，但没运行 composer update 或 composer install，锁文件没更新，命令就看不到这个新包的存在。
关键动作顺序：
- 编辑
composer.json→ 运行composer update vendor/new-package（精准更新）或composer install（按 lock 安装） - 再执行
depends/prohibits，否则查的是旧状态 - 如果只是想预判影响，用
composer why vendor/new-package（等价于depends）+--dry-run不可行——Composer 没这个参数，必须真更新才能验
最常被忽略的一点：CI 环境里 composer install 如果用了 --no-scripts 或跳过 autoload 生成，depends 仍能运行，但结果可能和本地不一致，因为某些插件或自定义 installer 会影响依赖解析逻辑。