Composer怎么查包被谁依赖_反向依赖分析方法【实用】-composer-PHP中文网

composer depends 是唯一能直接查本地反向依赖的命令，从 composer 2.2 起稳定内置，仅读取 composer.lock 和 vendor/ 目录，结果即当前项目真实依赖快照；报“package not found”说明目标包未安装，需确认拼写、执行 install/require 并检查是否被 replace。

composer怎么查包被谁依赖_反向依赖分析方法【实用】

composer depends 是唯一能直接查本地反向依赖的命令

它从 Composer 2.2 开始稳定内置，不需要插件、不依赖外部服务，只读 composer.lock 和已安装的 vendor/ 目录，结果就是当前项目真实依赖快照。

常见错误是运行后报 Package not found——这说明目标包根本没被安装进当前项目，不是命令失效。必须先确认包名拼写完全一致（包括大小写、斜杠）、且已执行过 composer install 或 composer require。

用 composer show 列出所有已安装包，复制完整名称（如 symfony/console）再传给 depends
如果包只在 require-dev 里，它仍会被 depends 找到；但如果只是某个已安装包的 require-dev 依赖（即嵌套在 dev 依赖里），默认不显示，需加 --link-type=require-dev
composer depends vendor/package-name 默认只列直接依赖者；加 --tree 才会展开路径（注意：不是 --tree 参数本身属于 depends，而是 depends --tree 是合法组合）

为什么 --tree 展开后层级看起来“断掉”了

composer depends --tree 显示的是当前 composer.lock 中实际解析出的依赖链，不是理论上的所有可能路径。如果你刚改了 composer.json 但还没运行 composer update，树形结构就仍是旧的。

例如：myapp/myproject → guzzlehttp/guzzle → guzzlehttp/psr7 这条链只有在 guzzlehttp/guzzle 的 composer.json 确实声明了对 guzzlehttp/psr7 的 require，且该版本范围被 lock 文件锁定时，才会出现在 --tree 输出中。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

中断在某一层（比如只看到 laravel/framework 就停住），大概率是它通过 replace 或 provide 声明满足了目标包，此时需配合 composer show laravel/framework 查它的 provides 字段
--tree 不显示版本约束，只展示路径；要看具体 require 规则，得用 composer depends -w vendor/package-name（-w 即 --why）
输出中带 [dev] 后缀的节点，表示该依赖来自 require-dev，不影响生产环境，但影响开发时的类加载和测试

查不到结果？先排除这三类情况

空输出不等于没人用这个包，更可能是查询条件或环境不匹配。

包名写错：比如把 monolog/monolog 写成 monolog、Monolog/Monolog 或 monolog/monolog-php —— Composer 不做模糊匹配
包未安装：运行 composer show vendor/package-name，若报错 Package not found，说明它不在 vendor/ 里，depends 必然查不到
包被 replace 掉了：比如你 require 了 psr/log，但实际装的是 monolog/monolog（因后者 provides: "psr/log"），此时查 psr/log 会失败，得查 monolog/monolog 并看其 provides

别指望 composer depends 覆盖全局或预测未来

它只回答一个问题：“此刻，这个项目里谁在用这个包”。不会扫描 GitHub 上所有仓库，也不会告诉你“如果我升级 X，Y 会不会崩”。

想评估升级影响，必须分两步走：先用 composer depends --tree 锁定当前链路，再人工检查每条链路上的 composer.json 里对该包的版本约束是否兼容新版本。尤其要注意 ^、~、!= 这些运算符的实际覆盖范围，它们才是约束生效的关键。

真正容易被忽略的是：私有包、path 类型 repo、或通过 repositories 配置的非 Packagist 源，在 composer.lock 里可能没有标准字段，depends 仍能识别，但 --why 可能无法还原原始 require 行为——这时候得翻对应包的 composer.json 手动确认。