composer why vendor/package-name 可直接查出项目中显式或隐式依赖某包的来源，需用准确全名（如 monolog/monolog），返回“No dependencies”表示未被引用，“Could not find package”多因拼错或未安装；它仅显示第一层依赖者，完整链路需配合 composer show --tree。
composer why 显示谁在依赖某个包
直接用 composer why vendor/package-name 就能查出当前项目里哪个包（或根项目）显式或隐式依赖了指定包。它比手动翻 composer.lock 快得多，也比看 composer show --tree 更聚焦。
常见错误是输错包名——必须用 Composer 注册的全名，比如 monolog/monolog，不能写成 monolog 或 Monolog；大小写和斜杠都不能错。
- 如果返回 “No dependencies exist for …”，说明该包没被任何已安装包引用（可能是 dev-only、已废弃、或根本没装上）
- 如果提示 “Could not find package …”，八成是包名拼错了，或者该包根本不在
vendor/里（比如只在require-dev但当前没装 dev 包） - 它不显示间接层级深度，默认只展示第一层依赖者；想看完整链路，得配合
composer show --tree vendor/package-name
composer show --tree 查依赖树时怎么快速定位目标包
composer show --tree 输出的是整个依赖树，信息量大但难扫。真正有用的做法是用管道过滤：composer show --tree | grep -A 2 -B 2 "target-package"，这样能连带看到它的父级和子级，判断是不是被某个 dev 工具（比如 phpunit/phpunit）意外拉进来的。
注意：这个命令输出依赖关系是“安装后”的快照，受 composer.json 中 platform 配置、config.platform.php 和本地 PHP 版本影响。比如你本地是 PHP 8.2，但配置了 "platform": {"php": "8.1"}，那树里显示的可选版本可能和实际不符。
- 输出里带
[dev]标记的，说明该包来自require-dev，上线部署时可能被跳过 - 如果某包出现在多条路径下（比如被
laravel/framework和spatie/laravel-backup同时依赖），composer why只会返回第一个匹配项，得手动核对 - Windows 用户用 PowerShell 运行时，
grep要换成sls（即Select-String），否则过滤失效
为什么 composer depends 不起作用
composer depends 是 Composer 2.5+ 新增的命令，但很多人升级后仍用不了——因为默认安装的 Composer 可能还是 2.4 或更旧。运行 composer --version 确认是否 ≥2.5；不是的话，先执行 composer self-update。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
即使版本够，composer depends vendor/package 也只检查当前 composer.json 中声明的依赖项，不会扫描 vendor/ 下所有包的 composer.json。也就是说，它不如 why 实用，后者是动态解析已安装结构。
- 如果你看到
Command "depends" is not defined，别急着重装，先composer self-update -
depends不处理别名包（如psr/log-implementation），这类虚拟包得靠why+ 手动查provide字段 - 某些私有仓库包若未配置
repositories，depends会静默忽略，而why至少会报错提醒
删掉一个包前，怎么确认没其他包暗中依赖它
别只信 composer why 的单次输出。真实场景中，有些包通过 replace、provide 或插件机制（如 Laravel 的 ServiceProvider）建立弱依赖，why 压根不感知。
稳妥做法是三步走：先 composer why vendor/package，再全局搜代码里有没有 use 或 new，最后临时删掉并跑测试：composer remove vendor/package && vendor/bin/phpunit。很多“没被依赖”的包，一跑测试就暴露——比如日志驱动、缓存适配器这类基础设施。
- 搜索代码时，别漏掉注释里的
@see或配置文件（config/app.php、phpunit.xml）里的类名引用 - 如果项目用了 Psalm/PHPStan，它们的类型分析有时比 Composer 更早发现隐式依赖
- CI 环境里
composer install --no-dev后再试why，能排除 dev-only 引入的干扰
依赖关系不是静态图谱，而是随 PHP 版本、平台配置、安装参数实时变化的动态快照。最可靠的验证永远发生在删之前跑一次 composer update --dry-run，看它打算卸载哪些东西。
