composer show -t 默认展开全部依赖导致信息混乱，建议用 --no-dev、grep 定位、composer-dependency-graph 可视化，并注意版本约束对依赖树的动态影响。
composer show -t 显示依赖树但信息太乱？
默认 composer show -t 会把整个依赖图展开，顶层包以下所有递归依赖全打出来，尤其项目用了 Laravel、Symfony 这类大生态时，一眼根本找不到关键路径。它不区分 dev 依赖、不折叠重复子树、也不标版本冲突。
实操建议：
- 加
--no-dev排除开发期依赖，聚焦运行时真实链路：composer show -t --no-dev - 用
grep快速定位某包在哪一层：composer show -t | grep -A5 -B5 "monolog" - 如果只关心某个包的上游（谁依赖了它），用
composer show -t vendor/package-name，例如：composer show -t guzzlehttp/guzzle
graphviz + composer-dependency-graph 生成可视化图
纯文本树状图对嵌套深、交叉引用多的项目基本失效，这时候得靠图结构渲染。官方没内置图形导出，但社区工具 composer-dependency-graph 能把 composer.lock 转成 .dot 文件，再交给 graphviz 渲染成 PNG/SVG。
常见错误现象：安装后运行报 dot command not found —— 这不是 PHP 问题，是系统缺 graphviz 二进制。
实操建议：
- Mac 用户：
brew install graphviz；Ubuntu/Debian：apt install graphviz - 全局安装工具：
composer global require mablae/composer-dependency-graph（确保~/.composer/vendor/bin在$PATH） - 生成 PNG：
composer-dependency-graph --format=png --filename=deps.png - 若图太密看不清，加
--max-depth=2限制层级，或用--filter="laravel/*"只画特定命名空间
为什么 vendor/autoload.php 不代表实际加载顺序？
很多人以为「依赖图」就是自动加载顺序，其实不是。Composer 的 autoloader 是按 PSR-4/PSR-0 规则注册命名空间映射，和依赖声明顺序无关。真正影响加载行为的是 autoload 和 autoload-dev 配置，以及是否启用了 classmap 优化。
容易踩的坑：
- 手动修改
vendor/composer/autoload_classmap.php—— 下次composer install会被覆盖 - 在
composer.json里删掉某个包的require，但没删它的autoload配置，导致类仍可被加载，却无对应代码 - 使用
classmap时，如果目录下有同名但不同命名空间的类，会因文件路径优先而覆盖，引发静默加载错误
dev-master / ^2.0 / v1.2.3 版本约束怎么影响依赖图？
版本写法直接决定 Composer 解析依赖时的取舍范围，进而改变最终图结构。比如 "monolog/monolog": "^2.0" 允许装 2.x 任意小版本，但 "monolog/monolog": "dev-main" 会强制走 VCS 拉取，可能引入未稳定接口，还可能让其他依赖无法满足其 require 条件。
性能与兼容性影响：
-
dev-分支约束会导致每次composer update都去 Git 拉 HEAD，慢且不可重现 -
*或^0.x容易触发“依赖地狱”，尤其当多个包同时松绑低版本时，Solver 可能卡住几分钟甚至失败 - 用
composer prohibits vendor/package可查哪个包在阻止你升级，比硬看图更准
依赖图不是静态快照，它随 composer.json 中每个版本字符串的松紧程度实时变化，改一行约束，整棵树都可能重排。别只盯着图好看不好看，先盯紧版本写法本身。
