composer如何查看已安装的包和版本

冰火之心

发布时间：2025-09-22 16:17:01

495人浏览过

来源于php中文网

原创

使用composer show命令可查看已安装包及其版本，包括直接依赖和间接依赖，结合-i参数列出所有包，用composer show 查看特定包详情，实际安装版本以composer.lock为准，遵循语义化版本规范，配合composer update、install、require等命令实现完整依赖管理。

composer如何查看已安装的包和版本

要查看Composer项目已安装的包及其版本，最直接有效的方式是使用

composer show

命令。这个命令能帮你快速掌握项目依赖的概况，无论是顶层依赖还是深层的间接依赖，都能一目了然。

解决方案

在Composer项目中，查看已安装的包和版本主要依赖于

composer show

命令。它不仅能列出所有安装的包，还能显示它们的版本信息，甚至包括它们的依赖关系。

首先，最基础的用法是在项目根目录下运行：

composer show

这个命令会列出所有作为你项目直接依赖（在

composer.json

中明确声明的）的包，以及它们当前安装的版本。通常，你会看到包名后面跟着一个版本号，比如

monolog/monolog 2.x-dev

或者

symfony/console v6.3.4

。

如果你想看到所有已安装的包，包括那些作为其他包的依赖而被拉进来的（也就是间接依赖），你需要加上

-i

（或

--installed

）参数：

composer show -i

这会给出一个更长的列表，因为它包含了整个依赖树中所有实际安装到

vendor

目录下的包。这对于理解项目的完整依赖图谱非常有用，有时候你会发现一些你从未直接引入但却被某个依赖包需要的组件。

如果你的目标是查看某个特定包的详细信息，比如它的描述、作者、许可证、甚至它自己的依赖，可以这样用：

composer show

例如，要查看

monolog/monolog

的详细信息，你可以运行：

composer show monolog/monolog

这会返回一个包含版本、类型、许可证、来源、依赖等信息的综合报告。我个人觉得这个命令在排查问题时特别有用，比如你想确认一个包是否真的安装了某个特定版本，或者它的依赖是否满足你的预期。

为什么我看到的版本和

composer.json

里写的不一样？

这其实是很多Composer新手会遇到的一个“困惑点”，但理解了背后的机制，就会觉得非常合理。简单来说，

composer.json

文件定义的是你项目“期望”的依赖版本范围，而

composer.lock

文件记录的才是Composer“实际安装”的精确版本。

composer.json

里的版本约束通常是灵活的，比如

^1.0

、

~1.2

或者

1.x-dev

。这意味着Composer在满足这些约束的前提下，可能会安装最新兼容的版本。当你运行

composer install

或

composer update

时，Composer会根据

composer.json

的约束计算出一个可行的依赖图，并把所有包的精确版本、哈希值等信息写入

composer.lock

文件。

通吃客零食网整站 for Shopex

第一步】：将安装包中所有的文件夹和文件用ftp工具以二进制方式上传至服务器空间;(如果您不知如何设置ftp工具的二进制方式，可以查看：(http://www.shopex.cn/support/qa/setup.help.717.html)【第二步】：在浏览器中输入 http://您的商店域名/install 进行安装界面进行安装即可。【第二步】：登录后台，工具箱里恢复数据管理后台是url/sho

下载

所以，当你使用

composer show

命令查看已安装包的版本时，你看到的是

composer.lock

文件里记录的，也就是

vendor

目录下实际存在的版本。这个版本是确定的、精确的，因为它保证了所有开发人员和部署环境都能安装到完全相同的依赖版本，避免了“在我的机器上能跑”的问题。

如果

composer.json

和

composer.lock

中的版本看起来有差异，或者你对当前

vendor

目录下的实际版本有疑问，记住

composer.lock

是真相的来源。如果需要更新到

composer.json

里允许的最新版本，你就需要运行

composer update

，这会重新计算依赖并更新

composer.lock

。

查看包信息时，如何理解版本号的含义？

理解版本号的含义，特别是语义化版本（Semantic Versioning，简称SemVer），对于维护Composer项目至关重要。大多数Composer包都遵循SemVer规范，即版本号由三部分组成：

MAJOR.MINOR.PATCH

（主版本号.次版本号.修订号）。

MAJOR（主版本号）：当你对包进行了不兼容的API更改时，需要递增主版本号。这意味着升级主版本号通常需要你修改自己的代码来适应新的API。比如从
```
1.x.x
```
升级到
```
2.x.x
```
。
MINOR（次版本号）：当你增加了向后兼容的新功能时，需要递增次版本号。升级次版本号通常是安全的，不会破坏你的现有代码，但会带来新功能。比如从
```
1.0.x
```
升级到
```
1.1.x
```
。
PATCH（修订号）：当你进行了向后兼容的bug修复时，需要递增修订号。这是最安全的升级，只修复问题，不引入新功能或不兼容改动。比如从
```
1.0.0
```
升级到
```
1.0.1
```
。

此外，你可能还会看到一些版本号后面跟着

alpha

、

beta

、

RC

（Release Candidate）或

dev

等后缀。这些表示预发布版本，通常不稳定，不建议在生产环境中使用。

在

composer.json

中，你还会看到一些版本约束符号，比如：

```
^1.0
```
(caret)：表示兼容
```
1.0.0
```
到
```
2.0.0
```
之间，但不包含
```
2.0.0
```
的任何版本。这是Composer中最常用的约束，意味着允许次版本号和修订号升级，但主版本号不变。
```
~1.2
```
(tilde)：表示兼容
```
1.2.0
```
到
```
1.3.0
```
之间，但不包含
```
1.3.0
```
的任何版本。它允许修订号升级，但次版本号不变。
```
1.x
```
或
```
1.*
```
：表示兼容所有
```
1
```
开头的主版本号，次版本号和修订号可以任意。

理解这些，就能更好地判断一个包的更新是风险大还是小，以及你的项目是否能安全地升级到某个新版本。

除了查看版本，还有哪些命令可以帮助我管理已安装的包？

Composer不仅仅是一个查看工具，它更是一个强大的依赖管理工具。除了

composer show

，还有几个核心命令能帮助你更好地管理项目的依赖：

```
composer update
```
: 当你需要将项目依赖更新到
```
composer.json
```
文件中允许的最新版本时，就用这个命令。它会重新计算依赖，下载新版本，并更新
```
composer.lock
```
文件。如果你想更新某个特定包，可以指定包名，比如
```
composer update monolog/monolog
```
。这在开发过程中，当你想要获取某个包的最新功能或修复时非常常用。
```
composer install
```
: 这个命令的作用是根据
```
composer.lock
```
文件中记录的精确版本来安装所有依赖。如果
```
composer.lock
```
不存在，它会根据
```
composer.json
```
来生成一个并安装。在部署项目到生产环境或者团队成员初次设置项目时，
```
composer install
```
是首选，因为它能保证所有环境的依赖版本完全一致。
```
composer require 
```
: 当你需要向项目中添加一个新的依赖包时，这是最便捷的方式。它不仅会下载并安装这个包，还会自动将其添加到
```
composer.json
```
的
```
require
```
部分，并更新
```
composer.lock
```
文件。比如
```
composer require symfony/yaml
```
。
```
composer remove 
```
: 顾名思义，这个命令用于从项目中移除一个已安装的依赖包。它会删除
```
vendor
```
目录下的相应文件，并从
```
composer.json
```
和
```
composer.lock
```
中移除其记录。比如
```
composer remove monolog/monolog
```
。
```
composer outdated
```
: 这是一个非常有用的命令，它会列出所有已安装的、并且有新版本可用的包。这能让你一目了然地知道哪些依赖可以升级，并且会提示你当前版本、最新稳定版本和最新开发版本。这对于定期检查项目健康状况和及时获取安全更新非常关键。