使用composer show命令可查看已安装的包列表，包括直接与间接依赖；通过composer show -i可聚焦直接依赖，composer show -t以树状结构展示依赖关系，composer depends命令则用于追踪某包被谁依赖；结合composer why-not和composer.lock文件分析，能有效排查版本冲突并生成依赖报告，便于团队协作与审计。
要查看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的错误信息虽然详细，但有时也需要一些技巧去解读。
表单大师AI
一款基于自然语言处理技术的智能在线表单创建工具，可以帮助用户快速、高效地生成各类专业表单。
74 查看详情 
我记得有一次，一个老项目死活不让我升级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包，可以检查你的依赖是否存在已知的安全漏洞。
我们团队内部就遇到过一个问题，新来的同事在本地
composer install
之后，跑测试老是出问题，后来才发现是
composer.lock
文件没更新到最新。所以，定期检查并共享这个文件，或者生成一个可读性强的报告，真的能省不少事，也能确保所有开发环境的一致性。选择哪种方法，取决于你的具体需求和团队的工作流程。
以上就是Composer如何查看已安装的包列表_项目依赖清单展示与管理的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/261830.html
微信扫一扫 
支付宝扫一扫 
