下面由composer教程栏目带大家回顾一下composer，希望对需要的朋友有所帮助！
composer是php社区推荐的依赖管理工具。composer之于php犹如npm之于node，几乎是做现代化php开发的必备技能。本文简要回顾相关概念和composer用法。
拓展和包与之相关的概念是框架和库，关于框架和库的区别，可以查看本人之前写的这篇文章
拓展和包是两个非常相近的概念。在php世界里，一般可以这样理解和区分两者：拓展（extension）和模块（module）等价，是用c语言写的功能合集；包(package)和库（library）等价，主要是用php实现的功能合集；拓展以动态链接库（dll或so）的形式加载，包则是通过require/include方式加载。绝大部分时候，两者混用不会造成理解上的困难。
常见的拓展包括gd、zip、xml、mysqli、opcache等，常见的包包括phpmailer、phpoffice、htmlpurifier等。
pear和pecl在composer流行之前，pear和pecl是更为php开发者所知的两个工具（社区）。pear是php拓展和应用仓库（php extension and application repository）的缩写，官网http://pear.php.net ；pecl是php拓展社区库（php extension community library）的缩写，官网http://pecl.php.net。
两者的区别可用拓展和包来区分：pecl托管拓展，源代码多为c文件，例如apc、ampq等；pear托管包，功能用php实现，如php codesniffer、http request等；pear对应pear命令，pecl对应pecl命令，可用这两个命令安装和管理拓展和包（pear的build/pickle子命令也可以编译pecl中的拓展）。两者互为补充，官网以姐妹（sisters）形容两者的关系。
pecl是官方拓展的补充，目前仍处于活跃状态，一些优秀的拓展有成为官方拓展的潜质。韩天峰大神的swoole拓展也托管在pecl中，国内名气非常高。相比之下pear已是明日黄花。pear2和pyrus（下一代的pear包安装工具，基于php5.3+构建，官网http://pear2.php.net）的出现也未能挽救pear。pear没落伴随着本文主角composer的兴起。
pear的定位是“提供可复用的php组件”，以中心化的方式为开发者提供功能包。中心化发布的方式保证了代码的质量，同时带来维护上的不便：通过评审的包才能发布，包过时现象严重。pear安装的包是全局的，不能为单独项目安装依赖包，非特权用户不能自行安装依赖包。其他缺点还包括糟糕的依赖管理。随着github的流行和composer的出现，包管理进入composer时代。pear已经完成其历史使命，可以安心的去了。
composer严格来说，composer的定位是依赖管理工具而非包管理器。composer中文网对composer工作介绍如下：
composer 将这样为你解决问题：a) 你有一个项目依赖于若干个库。
b) 其中一些库依赖于其他库。
c) 你声明你所依赖的东西。
d) composer 会找出哪个版本的包需要安装，并安装它们（将它们下载到你的项目中）。
pear能做的事情，composer都能做（包括安装pecl拓展），部分还能做得更好。composer默认把包安装在项目目录下，普通用户就能正常使用（composer官方建议不要以root身份执行composer命令）；鼓励遵循最佳实践（即大名鼎鼎的psr规范，详情见php-fig官网https://www.php-fig.org），极大的推动php社区编码风格的规范化；composer是去中心化的平台，任何人均可发布代码包；发布包无需评审，包的质量由用户投票决定...作为pear的继任者，composer的表现经受住了社区的考验，并成为事实上的依赖管理标准工具。
composer目前已经形成庞大的生态，在数量上，composer的包远超pear。由于任何人均可自由发布包且无需评审，composer生态中的包可能存在代码质量参差不齐、代码风格各异、后门漏洞等隐忧。另外composer的依赖管理以项目为单位，一台机器上可能多次安装同一个包。但瑕不掩瑜，总体而言，composer极大的改变了php的开发生态，促进了代码交流和社区发展。
composer用法composer为管理的项目的依赖而生，项目中的composer.json文件是其工作的依据。该文件中最重要的部分是require部分，该部分告诉composer期望安装的包及其版本，例如：
{    name: tlanyan/foo,    version: 1.0.0,    ....    require: {        php: >=5.4.0,        yiisoft/yii2: >=2.0.6,        yiisoft/yii2-swiftmailer: *,        yiisoft/yii2-redis: >=2.0.0,        smarty/smarty: < =3.1.25,        yiisoft/yii2-smarty: >=2.0.0,        phpoffice/phpexcel: >=1.8.0,        tecnickcom/tcpdf: ~6.2.0    },    ....}
然后运行composer install命令，composer会自动分析依赖，安装最合适的包到vendor目录下。加-v(-vv, -vvv)选项会打印命令执行过程中的详细信息。安装完毕后，vendor目录下会生成autoload.php文件。在项目的入口文件中包含此文件： require __dir__ . /vendor/autoload.php;，接下来便可在项目的任何地方引用依赖包中的接口和类。
除install命令，composer提供了许多其他命令管理依赖。常用的命令场景包括：查找依赖、引入依赖、安装依赖、更新依赖。分别对应的命令是：
composer search: 根据关键字查找依赖包，例如查找本人发布的包：composer search tlanyan。该命令等同于上https://packagist.org进行包查找；composer require: 引入依赖，声明项目或者全局(global，用户名全局，非系统全局)依赖某个包， 例如声明需要swiftmailer包： composer require [global] swiftmailer/swiftmailer:dev-master；该命令更新composer.json文件，并默认立即安装依赖（--no-update选项可阻止默认安装）；效果等同于编辑composer.json文件，然后执行install命令；composer install：安装composer.json声明的依赖包，最终安装的依赖包版本可能取决于有无composer.lock文件；composer update： 更新依赖到最新版本，相当于删除composer.lock文件后执行composer install。以上四条命令涵盖使用composer的大部分场景。以下是几个常用的辅助命令，与依赖分析相关：
composer info： 查看安装的依赖包信息，与composer show等价；composer dumpautoload： 加-o选项可导出优化的加载器；composer why(-not)： 查看（不）安装某个包的原因。总结从拷贝第三方代码到项目中(1994)，到pear安装依赖包(1999)，再到composer兴起(2012)，php社区经历了将近20年的探索。php这门古老的语言，也在不断的发展更新，在web领域一直发光发热。composer作为目前php包依赖管理的最佳工具，值得每一位php开发人员掌握。
以上就是回顾一下composer的详细内容。