Composer依赖层级：理清主依赖与次要依赖的引用逻辑

Composer依赖层级：理清主依赖与次要依赖的引用逻辑

先明确一个核心事实：Composer 从不区分什么“主依赖”和“次要依赖”——所有写在 require 里的条目，在依赖解析时地位完全平等。最终哪个版本能胜出，是由 SAT 求解器统一权衡所有约束条件决定的，跟你书写的顺序、或者它在依赖树里缩进了多少格，没有半点关系。

上面这段缩进文本，其实就是这个平等原则的视觉化体现。它仅仅表示：每缩进一级（通常是两个空格），就代表一层直接的 require 关系。它不反映重要性，不决定加载顺序，更不代表运行时的调用链条。

composer show -t . 显示的缩进到底代表什么

说白了，这缩进就是一张“依赖家谱”的文本版。比如你看到 guzzlehttp/guzzle 下面缩进了一个 psr/http-client，那只能说明一件事：Guzzle 自己的 composer.json 里白纸黑字写着 "require": {"psr/http-client": "^1.0"}。

千万别把这缩进当成“重要性排名”或者“加载优先级表”，那就完全跑偏了。它跟自动加载机制、运行时谁调用谁、乃至 classmap 的覆盖逻辑，统统不沾边。

理解这点，就能看明白几个常见现象：

• 同一个包在不同深度重复出现（比如一次在2级，一次在4级），这大概率是被多个上游包分别引入了。一旦它们要求的版本不一致，冲突的导火索就埋下了。
• 默认情况下，composer show -t . 只扫描 require 部分，require-dev 里的包不会露面，除非它们被某个生产依赖间接拖了进来。
• 如果终端窗口太窄，缩进可能会显示错乱。这时候，加上管道命令 | less -S 横向滚动查看会更清晰：composer show --no-dev -t . | less -S。

composer depends 和 composer show --who 的核心区别

这两个命令都用来追查依赖来源，但路数截然不同。composer depends 像个侦探，反向追踪“谁把我拉进了这个项目”，不过它默认只展示直接依赖链，而且在 Composer 2.4+ 版本里属于实验功能，默认是关闭的。

相比之下，composer show --who 就稳定、直接得多。它的任务很单纯：扫描所有已安装包的 require 和 require-dev 字段，然后列出直接声明了目标包的那些包名。

• 想知道谁用了 psr/log？直接跑 composer show --who psr/log，结果可能显示是 monolog/monolog。
• 想排除开发环境的影响？加上 --no-dev 选项过滤一下：composer show --who --no-dev psr/log。
• 如果命令返回空结果，也别急着下结论说没人用。很可能这个包是通过虚拟包（比如 psr/log-implementation）间接提供的。这时候，就该回头去查 composer show -t . 看整体结构了。

为什么你写的 require 未必能“压住”间接依赖的版本

这是Composer依赖管理最关键的逻辑之一：它的解析过程不是“先装我写的，再装它带的”这种线性操作，而是把所有约束——包括你项目里写的 require、其他包声明的 conflict、甚至PHP版本限制——统统扔进一个逻辑公式的大锅里，让SAT求解器去找出一组能同时满足所有条件的版本组合。

这意味着：

• 你在项目里明确要求 "lara vel/framework": "10.40.0"，但如果某个间接依赖强硬地声明它需要 "lara vel/framework": "^9.0"，求解器不会“二选一”或者“取最高版”，它会直接报错，告诉你此路不通。
• 遇到 Your requirements could not be resolved... 这种错误时，别浪费时间调整 composer.json 里的顺序。更有效的做法是，先用 composer why-not lara vel/framework:10.40.0 这个命令，查清楚到底是哪个包在“拦路”。
• 另外，require-dev 里的包虽然只参与开发环境的依赖求解，不影响 composer install --no-dev 的结果。但要注意，如果你在 require-dev 里写了和 require 冲突的版本约束，它依然会参与全局的约束计算，可能引发冲突。

说到底，依赖树上的缩进只是一张静态的关系快照。它既不体现版本约束的真正来源，也不反映虚拟包（provide）或包替换（replace）这些复杂行为。真想定位依赖冲突的根源，得学会交叉比对：把 composer show -t 的结构图、composer show --who 的溯源结果和 composer why-not 的冲突诊断结合起来看，而不是盯着某一层的缩进自己琢磨。这才是理清依赖引用的正确姿势。