如何查看Composer依赖关系（分析工具）-composer-PHP中文网

composer show -t 是唯一开箱即用的依赖树命令，读取 composer.lock 和 vendor/ 的真实快照，需先执行 composer install 或 update；支持项目级、生产环境、指定包及直接依赖查看，并可通过管道优化显示。

如何查看composer依赖关系（分析工具）

composer show -t 是唯一开箱即用的依赖树命令

别折腾 composer tree 或 composer graph，它们根本不存在——Composer 官方没实现，强行搜会浪费半小时。你现在能立刻执行、不装插件、不配环境的命令只有 composer show -t。

它读的是 composer.lock 和 vendor/ 的真实快照，不是理想声明，所以必须先 composer install 或 composer update 过，否则报 Package not found。

composer show -t .：查整个项目（点号 . 代表当前项目）
composer show --no-dev -t .：生产环境链路，--no-dev 必须写在 -t 前面，否则被忽略
composer show -t guzzlehttp/guzzle：只展开 Guzzle 及其下游，不扫全量，响应更快
composer show -t --direct：只显示你 composer.json 里显式写的 require，跳过子依赖干扰

终端太窄时缩进错位？加管道：composer show --no-dev -t . | less -S，-S 关闭自动换行，左右滑动看齐。

查“谁在用这个包”别信 composer depends

composer depends 是实验功能，默认关闭，遇到 provide、replace 或私有 path 仓库时大概率漏判。真正可靠的是 composer show --who 和 composer why --tree。

composer show --who psr/log：列出所有直接 require 它的已安装包（不含间接路径）
composer show --who --no-dev psr/log：过滤掉 phpunit 等开发依赖，聚焦运行时真实引用者
composer why --tree monolog/monolog：必须加 --tree，否则只返回一级上游（如 laravel/framework），看不到末尾是否出现 your-project-name dev-main —— 那才是你 composer.json 里亲手写的源头

如果 composer show --who 返回空，但 vendor/psr/log 确实存在，说明它是被子依赖“悄悄带进来”的，此时用 composer show -t . | grep -A5 -B5 psr/log 定位上下文，再对上层包逐级 show -t 上溯。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

文本树超过 200 行就该转图形化工具

缩进靠肉眼数，嵌套 >6 层、同一包在多处出现、版本括号里写着 [7.4.0] 和 [7.8.1] —— 这时候人脑已经不可靠了。图形化不是为了好看，是为看清循环依赖、版本冲突和孤立包。

composer-dependency-graph：最轻量，无需 Graphviz，生成交互式 HTML：composer require --dev kylekatarnls/composer-dependency-graph → ./vendor/bin/composer-dependency-graph
composer-visualize + Graphviz：导出 SVG/PNG，适合嵌入文档：brew install graphviz（macOS）→ composer global require bitexpert/composer-visualize → composer visualize --format=svg --output=deps.svg
私有镜像用户注意：composer-dependency-graph 默认只读 packagist.org，传 --repository 参数，URL 必须和 composer.json 中完全一致（结尾斜杠不能少）

图形工具不解决“为什么装了这个包”，只帮你看见结构；真正定位原因，还得回到 composer why --tree 和 composer prohibits。

依赖冲突时，tree 输出只是结果，不是原因

当你看到 composer show -t 里 guzzlehttp/guzzle [6.5.8]，但你明明写了 "^7.0"，这说明 Composer 已妥协降级——tree 显示的是 lock 文件里的快照，不是你的意图。

先跑 composer why guzzlehttp/guzzle，看哪个上游包在拉旧版
再跑 composer prohibits guzzlehttp/guzzle:7.*，找具体阻止升级的约束（比如某个包 require 了 "guzzlehttp/guzzle": "^6.0"）
composer update --dry-run 比 show -t 更接近真实 resolve 行为，尤其在冲突场景下

最易被忽略的一点：改完 composer.json 后，不 composer update 就跑 show -t，看到的永远是旧树——它不会主动同步声明变更。