告别手动维护依赖树：使用Composer依赖可视化工具生成直观架构图

Composer 自己并不提供依赖图的自动生成能力，这事得靠第三方工具来干。核心原因在于 composer show --tree 这类文本展示方式，根本识别不了循环引用、版本冲突和平台约束 —— 这些恰恰是项目结构化最需要排查的硬伤。而 composer depends 和 composer dependents 也仅仅是文本诊断工具，用于追踪影响范围，既不出图，也不检查兼容性。

Composer 自身并不支持画依赖图，必须依靠第三方工具。而 graphviz 是最底层的绘图引擎——没有它，再好的 PHP 工具也只能空转，根本出不了图。

为什么 composer show --tree 不够用

文本树最大的问题是：层级一深，你根本没法快速判断循环引用、重复加载，或者可选依赖的激活路径到底对不对。举个例子：monolog/monolog 同时被 lara vel/framework 和 phpunit/phpunit 拉进来，但文本展开里看不出哪个版本最终生效，更看不到 ext-json 这类平台约束是否真被满足。

常见的坑是：composer install 明明成功了，一运行却报 Class not found。这往往是因为依赖图里某个分支被意外剪枝了——而文本树完全无法暴露这种隐患。

composer dependents 和 composer depends 的真实用途

这两个命令不是画图工具，而是定位影响范围的诊断指令：

• composer depends vendor/package 查谁依赖了指定包（删包前评估破坏面时非常好用）
• composer dependents vendor/package 查该包被哪些其他包间接依赖（判断能否安全升级的关键参考）

注意，它们输出纯文本，不生成图像，也不校验兼容性。别指望靠它们看出 symfony/console v5 和 v6 能否在同一项目中共存——它只告诉你“有这个依赖关系”，不告诉你“是否冲突”。

真正能出图的组合：composer-visualize + graphviz

目前最稳定可用的方案是 composer-visualize（注意不是 composer-graph，后者已经多年不维护，也不支持 Composer 2.2+）。具体操作分三步：

• 先全局安装：composer global require bitexpert/composer-visualize
• 确保系统装了 graphviz（macOS 用 brew install graphviz，Ubuntu 用 apt install graphviz）
• 在项目根目录运行：composer visualize --format=png --output=deps.png

几个参数值得记住：

• --format=svg 比 png 更适合放大查看，不过需要浏览器打开
• --filter=vendor/name 可以聚焦单个包的上下游，避免整张图信息过载
• 默认会忽略 require-dev，加 --dev 才把测试依赖加进来——很多循环引用恰恰藏在这里

性能方面提个醒：如果项目包含 100+ 个包，生成图可能会卡顿。建议先用 composer show --direct 锁定主干依赖，再配合 --filter 生成。

图出来之后，重点看哪几处

可视化不是为了好看，而是为了快速定位三类硬伤：

• 箭头双向闭环 → 实锤循环依赖，必须砍掉其中一端的 require
• 同一包出现多个版本节点（例如 guzzlehttp/guzzle:7.4 和 7.8 并存）→ 检查 composer.lock 是否被手动改过，或者存在 replace 冲突
• 某个 ext-xxx 节点悬空无入边 → 说明该扩展没被任何包声明为必需，可能是遗留配置

最容易被忽略的是 dev 依赖带来的隐式耦合。图里 phpunit 拉进来的 sebastian/exporter，如果反向依赖了你的 src/ 目录，那就意味着单元测试代码已经和业务逻辑缠绕在一起，重构时非常容易断裂。