composer show -t 是查看当前项目实际安装依赖树的最直接方式,仅显示 vendor/ 中已安装包及其递归子依赖,不包含未安装或未启用的开发依赖;加 --dev 可包含 require-dev 包,指定包名可查其依赖链,配合 -t 与 depends 可反向追踪引用源头。

composer show -t 显示树状依赖关系
这是最直接的方式,composer show -t 会递归列出当前项目所有已安装包及其子依赖,形成缩进式树形结构。它只反映 vendor/ 里实际安装的版本,不包含未安装的可选依赖或 require-dev 中未启用的包(除非你加了 --dev)。
常见错误是直接运行 composer show 不带 -t,结果只得到平铺列表,看不出谁依赖谁;还有人误以为 -t 能显示冲突或未满足的约束,其实它只展示“当前成功安装的状态”。
- 想看开发依赖?加上
--dev:composer show -t --dev - 只想查某个包的依赖链?在后面指定包名:
composer show -t monolog/monolog - 输出太长看不清?可以管道给
less或重定向到文件:composer show -t > deps-tree.txt
composer depends 查某个包被谁引用
当你想定位一个底层包(比如 symfony/polyfill-php80)为什么被装进来时,composer depends 是关键。它反向查找哪些包直接或间接依赖了目标包,帮你快速识别“引入源头”。
注意它默认只显示直接依赖者(一级引用),不会展开整个上游链——这点容易误解。例如 composer depends doctrine/dbal 可能只返回 laravel/framework,但真正触发安装的可能是你自己的 AppServiceProvider 里用了 DBAL 的某个类,而框架只是中转。
- 要显示完整路径(包括间接依赖)?加
-t参数:composer depends -t doctrine/dbal - 区分运行时和开发时依赖?用
--dev或--no-dev控制范围 - 结果为空?说明该包未被任何已安装包声明为依赖,可能是被
autoload手动加载、或通过插件动态引入,不属于 Composer 管理的依赖图谱
依赖图谱不准?检查 lock 文件与 vendor 状态是否一致
你看到的树状图,本质是 vendor/composer/installed.json 的快照,而它只在 composer install 或 update 后更新。如果手动删过 vendor/ 里的某些包、或改过 composer.json 但没运行 install,show -t 就会显示过期甚至错误的结构。
另一个常见干扰是 platform 配置。比如你在 composer.json 里写了 "platform": {"php": "8.1"},但本地 PHP 实际是 8.2,某些 polyfill 包可能就不会被装入 vendor,导致依赖树里“消失”,但这不是 bug,是 Composer 根据平台约束做的裁剪。
- 强制刷新状态?运行
composer install --no-dev(或带--dev)再试 - 怀疑 lock 文件过期?先
composer update --dry-run看差异,别直接更新 - CI 环境下图谱异常?确认是否用了
--ignore-platform-reqs,这会让依赖解析跳过 PHP 版本等检查,导致本地和 CI 的树不一致
可视化依赖图?别依赖浏览器插件或第三方工具
有人搜“Composer 依赖图可视化”,然后装一堆 Node.js 工具或 PHP Web UI,结果发现它们要么解析 composer.lock 不准,要么把 require-dev 和生产依赖混在一起,甚至把未启用的 provide 声明也画进去,反而误导判断。
真正可靠的方式,是用 Composer 自带命令导出结构化数据,再用轻量脚本处理。比如 composer show -N --format=json | jq '.[] | select(.name | startswith("symfony/"))' 这类组合,比图形界面更可控。
- 需要导出为 DOT 格式画图?用社区脚本如
composer-dot,但它依赖composer show -t输出,前提仍是 vendor 状态干净 - 警惕“一键生成 PNG”的工具——它们往往缓存旧结果,且无法体现
conflict或replace规则的实际影响 - 团队协作时,与其共享图片,不如共享一段可复现的
composer show -t xxx命令和对应composer.lock的 Git commit hash
vendor/ 状态、composer.lock、PHP 平台配置三者共同影响。最常被忽略的是:你以为在看“项目依赖”,其实只是“当前 vendor 目录里凑巧装上的那些包”的快照。










