composer show -t 是唯一可靠依赖分析命令，因官方未提供图形化命令且旧版已弃用；需加点号指定当前项目，加 --no-dev 避免干扰，配合 less -S 查看；可视化需插件生成图表，但依赖树不反映自动加载顺序。
直接看 composer show -t，它就是你现在最该用、也唯一能无条件跑通的依赖分析命令。别试 composer show --tree，2.2+ 版本已弃用，会报错。
为什么 composer show -t 是唯一可靠起点
Composer 官方没提供图形化命令，graph、viz、show -tree 全都不存在或已失效。只有 show -t 是 Composer 2.x 稳定支持的原生命令，且不依赖插件、不挑环境。
-
composer show -t .：点号代表当前项目，必须加，否则报Not enough arguments -
composer show -t guzzlehttp/guzzle：聚焦单个包，向下展开其子依赖链，避免全量树干扰 - 输出中带
[v7.8.1]的括号内容是实际安装版本，不是composer.json里写的约束——看到v6.5.8却写了"^7.0"，说明被其他包强制降级了 - 缩进 = 依赖层级，每级缩进代表一次
require声明，不是重要性或加载顺序
composer show -t 容易踩的三个坑
它看起来简单，但默认行为极易误导判断：
- 不加
--no-dev就会混入phpunit、nikic/php-parser等 dev 包拉进来的旧版 polyfill，导致误判冲突源头 -
composer show -t | grep monolog可能漏掉深层嵌套中的同名包——因为同一包在不同缩进重复出现时，只展开第一次，后续折叠显示 - 终端宽度太小会导致缩进换行错位，建议管道进
less -S：composer show -t --no-dev . | less -S - 如果某包没出现在树里，先运行
composer install或composer update，确保composer.lock同步；show -t只展示实际解析并安装的包
什么时候必须离开文本树，上可视化图
当你要回答“谁在控制日志流向”“symfony/console 被多少路径引入且版本是否一致”，纯文本树已经失效——你得手动数空格、反复 grep、比对版本，效率极低。
- 首选方案：
composer global require markuspoerschke/composer-dependency-graph，然后运行composer-dependency-graph --format=png --output=deps.png - 若报
Class 'Graph' not found，说明插件依赖未装全，加--no-plugins重试，或手动composer require graphp/graph - 生成 HTML 图（
--format=html）后不能双击打开，会因 CORS 失效；需起本地服务：python3 -m http.server 8000，再访问http://localhost:8000/deps.html - 图太密看不清？加
--max-depth=2或--filter="laravel/*"限定范围
真正容易被忽略的底层事实
所有依赖图（无论文本还是图形）都不反映自动加载行为。vendor/autoload.php 的加载顺序由 PSR-4 映射和 classmap 优化决定，和 show -t 的缩进完全无关。你看到的“依赖树”，只是 composer.json 中 require 字段的静态声明关系，不是运行时调用链，也不是类加载优先级。想查某个类到底从哪加载，得看 composer dump-autoload -a 后的 vendor/composer/autoload_classmap.php。
