不能。composer show -t仅输出文本树形结构，非图形化图表；需用graphviz+composer-graph生成真实依赖图，通过dot渲染为png等格式，才能直观识别循环依赖、重复引入等问题。
composer show -t 能不能直接画出依赖图
不能。composer show -t 只输出文本树形结构，不是图形化图表，也不生成图片或 HTML。它适合快速扫一眼层级，但无法直观识别循环依赖、重复引入、或跨包的间接冲突。
用 graphviz + composer-graph 生成真实依赖图
这是目前最可靠、可复现的可视化方案，核心是把 Composer 的依赖数据转成 dot 格式，再交给 dot 命令渲染：
- 先装系统级 Graphviz：
brew install graphviz（macOS）、apt install graphviz（Ubuntu） - 全局安装可视化工具：
composer global require clue/graph-composer - 在项目根目录运行：
graph-composer --format=png --output=deps.png
生成的 deps.png 会清晰标出包名、版本、依赖方向；箭头粗细默认不反映权重，但能一眼看出哪个包被引用最多（入度高）。
为什么 vendor/composer/installed.json 不宜直接解析画图
这个文件只存已安装包的扁平列表和自身 require 字段，**不含递归解析后的完整依赖路径**。比如 A → B → C，installed.json 里 C 的 require 是空的，B 的 require 有 C，但 A 的 require 未必列 C —— 这会导致你手动解析时漏掉传递依赖。
真正可靠的来源是：composer show --tree 的实时计算结果，或通过 Composer\Package\Locker API 加载 composer.lock 后调用 getDependents() / getDependencies() 方法遍历。
分析循环依赖和“幽灵包”时要注意什么
Composer 本身禁止直接循环（A → B → A），但可能通过 dev-require 和 require 的混合触发隐式循环，尤其在使用 path 仓库或 repositories 时。这时 graph-composer 会报错退出，而 composer check-platform-reqs 或 composer why-not xxx 才是更准的排查入口。
所谓“幽灵包”，指出现在 composer.lock 里、但没在 composer.json 的 require/dev-require 中显式声明的包——通常是某依赖的子依赖被更高版本覆盖后残留。这类包不会出现在 composer show 默认输出中，需加 -a 参数：composer show -a | grep "required by" 才能定位源头。
