Composer如何查看已安装的包列表_项目依赖清单展示与管理

下次还敢

发布时间：2025-09-21 17:38:01

386人浏览过

来源于php中文网

原创

使用composer show命令可查看已安装的包列表，包括直接与间接依赖；通过composer show -i可聚焦直接依赖，composer show -t以树状结构展示依赖关系，composer depends命令则用于追踪某包被谁依赖；结合composer why-not和composer.lock文件分析，能有效排查版本冲突并生成依赖报告，便于团队协作与审计。

composer如何查看已安装的包列表_项目依赖清单展示与管理

要查看Composer已安装的包列表，最直接的方式就是使用

composer show

命令。它能让你快速了解项目到底引入了哪些依赖，以及它们的版本信息。说实话，每次接手新项目，第一件事就是想搞清楚它的“家底”，也就是项目到底用了哪些依赖，这比看

composer.json

详细多了，因为后者只列出直接依赖，而

composer show

会把所有实际安装的都摊开给你看。

解决方案

了解项目依赖清单，主要通过Composer提供的几个命令和对

composer.lock

文件的理解来完成。

首先，最常用的就是

composer show

命令。

composer show
: 这个命令会列出所有已安装的包，包括直接依赖和间接依赖。输出内容通常包含包名、版本、以及简单的描述。
composer show -i
或
composer show --installed
: 如果你只想看那些直接被你的
```
composer.json
```
文件所依赖的包，加上
```
-i
```
参数会更清晰。它会过滤掉那些只是被其他依赖拉进来的包，让你聚焦于项目的核心依赖。不过，它依然会显示所有已安装的包，只是会标记出哪些是你的直接依赖。
composer show -t
或
composer show --tree
: 当你想搞清楚依赖关系链时，这个命令简直是神器。它会以树状结构展示所有包及其子依赖，一眼就能看出哪个包依赖了哪个版本，对于排查版本冲突特别有用。
composer show
: 想深入了解某个特定包？比如
```
composer show symfony/console
```
，它会显示该包的详细信息，包括版本、描述、许可证、依赖它的其他包等等。

其次，

composer depends

命令也很有用，不过它的侧重点略有不同。

composer depends
: 这个命令是用来回答“谁依赖了谁”的问题。比如你想知道
```
symfony/yaml
```
被哪些包依赖了，就可以运行
```
composer depends symfony/yaml
```
。这对于找出某个包为什么会被安装，或者为什么不能轻易移除它，非常有帮助。
composer depends --tree
: 同样，加上
```
--tree
```
参数可以更清晰地看到依赖的层级关系。

除了命令行，

composer.lock

文件也是一个宝藏。这个文件记录了项目安装时所有依赖的确切版本和哈希值，是保证项目在不同环境下一致性的关键。虽然它不是给人直接阅读的，但通过编程方式解析它，可以获取到最权威、最详细的依赖清单。

如何快速识别项目中的直接依赖与间接依赖？

这确实是个常见的问题，尤其是在大型项目中，依赖层级一深，很容易混淆。

项目中的直接依赖，就是你在

composer.json

文件的

require

或

require-dev

部分明确列出的那些包。它们是你项目运行或开发所必需的基石。而间接依赖（也叫传递依赖），则是这些直接依赖自身又依赖的其他包。它们不是你直接引入的，而是Composer为了满足你直接依赖的要求，自动安装的。

要快速识别它们，我通常会这么做：

查看
composer.json
: 这是最直接的来源。
```
require
```
和
```
require-dev
```
下面的就是你的直接依赖。
使用
composer show -t
: 这个命令会以树状结构展示所有依赖。树的根节点（也就是第一层）通常就是你的直接依赖，而它们下面的分支，就是间接依赖。比如，如果你看到
```
monolog/monolog
```
下面又有个
```
psr/log
```
，那么
```
monolog/monolog
```
是直接或间接依赖，而
```
psr/log
```
就是它的间接依赖。这种可视化方式非常直观。
对比
composer.json
和
composer show
的输出: 运行
```
composer show
```
会列出所有已安装的包。然后你可以对照
```
composer.json
```
里的列表，那些
```
composer show
```
列出但
```
composer.json
```
里没有的，基本就是间接依赖了。当然，如果
```
composer show -i
```
能满足你的需求，它本身就更侧重于展示直接依赖。

一开始接触Composer，我也没搞明白直接和间接依赖的区别，直到有一次升级一个核心库，结果牵连了一堆看似不相关的包，才意识到这其中的门道。理解这个区分，对于控制项目体积、排查依赖冲突，甚至进行安全审计都至关重要。

当依赖版本冲突时，如何利用Composer命令进行排查？

依赖版本冲突是Composer用户最头疼的问题之一，尤其是在维护老项目或者引入新的、有严格版本要求的库时。Composer的错误信息虽然详细，但有时也需要一些技巧去解读。

Subtxt

生成有意义的文本并编写完整的故事。

下载

我记得有一次，一个老项目死活不让我升级PHPUnit，

composer update

总是报错。最后发现是另一个非常老的依赖，它自己内部写死了对PHPUnit的某个旧版本有强依赖。

排查冲突，我通常会按以下步骤来：

仔细阅读Composer的错误信息: Composer在遇到冲突时，会给出非常详细的报告，指出是哪个包的哪个版本与哪个包的哪个版本产生了冲突，以及为什么。这是解决问题的第一手资料。
使用
composer why-not
: 这是解决版本冲突的“杀手锏”。比如，你的项目需要
```
symfony/yaml
```
的
```
^5.0
```
版本，但Composer报错说无法安装，因为它被某个包限制在了
```
^4.0
```
。你就可以运行
```
composer why-not symfony/yaml 5.0
```
。Composer会告诉你具体是哪个包、哪个版本，阻止了
```
symfony/yaml 5.0
```
的安装，并给出详细的依赖链。这个命令能帮你迅速定位到问题的根源。
结合
composer show -t
查看依赖树: 当
```
why-not
```
给了你方向后，使用
```
composer show -t
```
可以让你在全局视角下审视整个依赖关系。有时候，冲突并非直接发生在两个包之间，而是通过多层间接依赖传递下来的。树状图能帮你更好地理解这个复杂的网络。
使用
composer depends
追溯源头: 如果你发现某个包被限制在一个旧版本，但又不确定是哪个上游依赖导致了这个限制，可以使用
```
composer depends 
```
来查看哪些包依赖了它。这有助于你找到那个“罪魁祸首”。

解决冲突通常意味着你需要调整

composer.json

中的版本约束，或者寻找兼容性更好的替代库。有时，你甚至需要暂时锁定一个旧版本，等待上游依赖更新。关键在于，这些命令能给你提供足够的信息，让你做出明智的决策。

如何将项目依赖清单导出或生成报告，便于团队协作与审计？

将项目依赖清单导出或生成报告，对于团队协作、安全审计、许可证合规性检查以及新成员快速了解项目技术栈都非常重要。仅仅是口头描述或者让大家自己跑命令，效率会很低，而且容易出错。

有几种方法可以实现这一点：

简单的文本输出: 最直接的方式就是将
```
composer show
```
的输出重定向到一个文件：
```
composer show -i > project_dependencies.txt
```
或者，如果你需要更详细的树状结构：
```
composer show -t > project_dependencies_tree.txt
```
这种方法简单快捷，生成的文本文件易于阅读，适合快速分享或作为文档的一部分。但缺点是缺乏结构化数据，不方便进行自动化处理。
解析
```
composer.lock
```
文件:
```
composer.lock
```
是一个JSON格式的文件，包含了所有已安装依赖的精确版本、哈希值、来源等详细信息。它是项目依赖的权威来源。你可以通过编程方式（例如，用PHP脚本或Python脚本）解析这个文件，生成结构化的报告。如果你想快速地从命令行获取一些结构化数据，可以结合
```
jq
```
这样的JSON处理工具：
```
cat composer.lock | jq '.packages[] | {name: .name, version: .version, reference: .source.reference, license: .license}' > dependencies_report.json
```
这个命令会从
```
composer.lock
```
中提取每个包的名称、版本、引用（通常是Git提交哈希）和许可证信息，然后输出为一个新的JSON文件。这种方式非常强大，可以根据需要定制输出字段，生成高度结构化的报告。
利用第三方工具或集成到CI/CD流程: 很多现代的CI/CD（持续集成/持续部署）工具和安全审计服务都内置了对Composer依赖的分析功能。它们可以直接读取
```
composer.lock
```
文件，生成安全漏洞报告、许可证兼容性报告等。例如，像
```
Roave/SecurityAdvisories
```
这样的Composer包，可以检查你的依赖是否存在已知的安全漏洞。