composer depends 查不到包需先确认包名精确匹配且在项目根目录执行，它只查直接依赖、区分大小写和vendor名，不跨项目或识别replace/provide关系。
composer depends 查不到包？先确认包名是否精确匹配
composer depends 默认只查「直接依赖」，而且对包名大小写和版本号极其敏感。比如你装的是 monolog/monolog，但输成 Monolog/monolog 或 monolog（缺 vendor），命令会静默返回空——不是报错，是根本没匹配到。
实操建议：
- 用
composer show列出所有已安装包，复制完整vendor/name格式 - 加
--tree参数才能看到完整依赖链，否则默认只显示一级上游 - 如果包是
dev-main或带#commit-hash的安装方式，depends可能无法识别，优先用稳定版本测试
想看某个包被谁引用，但结果为空？检查是否在 root 项目里运行
composer depends 只在当前 composer.json 所在目录生效，不会跨项目或扫描全局 vendor。如果你在子目录（比如 packages/my-lib）里执行，即使该目录有独立 composer.json，也不会自动关联到主项目依赖树。
常见错误现象：
- 在 Laravel 的
app/目录下跑composer depends guzzlehttp/guzzle→ 返回空 - 实际该包由
laravel/framework间接引入，但你在非项目根目录执行，命令找不到上下文
正确做法：cd 到项目根目录（含 composer.json 和 vendor/ 的那一层），再执行。
composer tree 和 composer depends 的核心区别在哪
composer tree 是从当前项目出发，向下展开所有依赖层级；composer depends 是反向查找，从指定包出发，向上追溯哪些包依赖它。两者输出结构完全不同，不能互相替代。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
使用场景差异：
- 排查循环依赖、定位冲突来源 → 用
composer depends --tree - 评估升级某个包的影响范围（比如改了
symfony/event-dispatcher，哪些自定义包会受影响）→ 用composer depends symfony/event-dispatcher - 想快速看
phpunit/phpunit是谁拉进来的 →composer depends phpunit/phpunit比翻composer.lock直观得多
注意：composer tree 默认不显示开发依赖（require-dev），要加 --dev 才包含；而 depends 默认包含所有依赖类型。
依赖链太深看不清？用 grep 或 --path 过滤关键路径
大型项目跑 composer depends --tree some/package 可能输出上百行，真正关心的往往只是某条路径（比如从 laravel/framework 到目标包的链路）。原生命令不支持正则过滤，但可以结合 shell 工具。
实操建议：
- 用
composer depends --tree vendor/name | grep -A5 -B5 "laravel/"快速定位相关分支 - 加
--path参数（Composer 2.5+）可限制只显示经过某个包的路径，例如：composer depends --tree --path laravel/framework vendor/name - 旧版 Composer 没
--path，就老实用composer show vendor/name --tree倒着推，有时反而更清晰
容易被忽略的一点：某些包通过 replace 或 provide 声明“提供”了另一个包的能力，depends 不会把这类逻辑依赖算进去，只认真实安装的包关系。
