标签：logger 令行 完整 upd 方便 服务 难度 大于 需要
现代高级编程语言，依赖管理工具是必不可少的。Java有Maven，Python有pip，Nodejs有npm, 而在composer出现之前，PHP只有被广为诟病的Pear, 由于Pear实在太难用，很少PHP开发者用到这个工具。以致于PHP的开发生态很糟糕。
连一个像样的依赖管理工具都没有，让PHP这门占据了web网站开发?主流市场的语言很尴尬。开发过程中，要用到第三方的类库，需要去下载zip包，然后解压，放到相应的目录，处理好命名空间，自动加载的问题，如果这个第三方包还有其他依赖项，还要再次重复这个流程，看着隔壁家python和node.js一个命令行就搞定，显得php开发人员的操作既原始又滑稽。
这场面，好比：
所幸，金光闪闪的composer驾着七彩祥云来了，PHP终于有了真正意义的依赖管理工具。可以说，composer是现代PHP的基石。
composer解决了项目的依赖关系，且实现了自动加载。开发人员只需要几个命令行，就能获取其他开发者的包，PHP开发工作因此变得如同堆积木，可以根据业务的需求，快速方便地拆解组合代码。
奇怪的是，即使compoer已经诞生好些年了，而且所有主流框架都支持composer，可竟然还有不少PHP开发者不用这个工具。甚至还有人觉得composer加大了PHP的学习难度。
持有这种想法的人，就好像是一辈子都用纸笔手工记账，有朝一日，给他配置了电脑，跟他演示了excel是如何地强大。他不为新事物的强大感到震撼惊喜，而是蹙眉不满地说：“这东西太难学了，我还是习惯用纸笔”。
对于持有这种想法的人，我只能两手一摊。心态衰老的年轻人，如果他的内心一直在装睡，任谁也叫不醒。但时代的步伐可不会因为他们的拉后腿而停止前进，只会把他们远远甩在身后...
composer的安装步骤，在composr中文社区有详细的说明，点击查看
安装的流程很简单，归结为以下几步：
php -r "copy(‘https://install.phpcomposer.com/installer‘, ‘composer-setup.php‘);" # 下载安装脚本 － composer-setup.php － 到当前目录
php composer-setup.php # 执行安装过程
php -r "unlink(‘composer-setup.php‘);" # 删除安装脚本
sudo mv composer.phar /usr/local/bin/composer # 全局安装
composer config -g repo.packagist composer https://packagist.phpcomposer.com # 更换国内镜像源
安装完成后，查看composer版本
接下来，我们用composer来安装第一个包
以monolog包为例，这个包可以让开发者很方便地将日记写入到文件、数据库或其他储存介质中。
composer.json文件，写入以下内容{
"require": {
"monolog/monolog": "1.2.*"
}
}
composer install指令安装包依赖
composer已经为我们下载了monolog包，且生成了autoload.php自动加载文件
新建monolog.php文件，内容如下：
<?php
require ‘vendor/autoload.php‘;
use Monolog\Logger;
use Monolog\Handler\StreamHandler;
// create a log channel
$log = new Logger(‘name‘);
$log->pushHandler(new StreamHandler(‘monolog.log‘, Logger::WARNING));
// add records to the log
$log->warn(‘警告日志‘);
$log->err(‘错误日志‘);
运行脚本：
learnComposer php monolog.php
生成了日志文件monolog.log
[2018-07-12 14:18:14] name.WARNING: 警告日志 [] []
[2018-07-12 14:18:14] name.ERROR: 错误日志 [] []
只需一个配置文件composer.json，一行指令composer install，代码中引入autoload.php，即可完美地使用第三方包。接下来分析composer的包管理规范
什么是包？只要存在composer.json文件的代码都可以称之为一个包。
包名称由作者+项目名称组成。有些包作者名与项目名是相同的，如mustache/mustache
包名称一定要加上作者，避免冲突。如，同样的是小龙女这个角色，不同人演绎的效果完全不同。如果你只是说你要看小龙女，可能给你的是一个陈妍希版本的小笼包，而不是你一直仰慕的仙女刘亦菲。
那么，我们怎么根据一个包的项目名去获取包的信息呢？以mustache包为例：
点击进入包信息详情页，可以看到包的安装方法以及版本信息
除了在
composer.json中写包的安装信息，还可以通过composer require mustache/mustache这种方式直接安装
composer search指令查找
查看包的具体信息 composer show mustache/mustache --all
在composer.json中声明安装包时，需要指定包的版本，?版本号的指定有多种格式：
格式：1.0.2
最简单的指定方式，无歧义
可以定义多个范围，用逗号隔开，这将被视为一个逻辑AND处理。一个管道符号|将作为逻辑OR处理。 AND 的优先级高于 OR
>=1.0: 大于或等于1.0版本
>=1.0,<2.0: 大于或等于1.0，且小于2.0
>=1.0,<1.1|>=1.2: 大于或等于1.0且等于1.1，或者大于等于1.2
1.0.*: 只要满足以1.0开头的版本号均可
~下一个重要版本~1.2 相当于 >=1.2,<2.0
~1.2.3 相当于 >=1.2.3,<1.3
^大于指定的版本以下用实例演示版本号的区别：
清空根目录，composer.json内容为：
{
"require": {
"mustache/mustache": "2.6.0"
}
}
执行composer install
接下来，删除vendor目录，将版本号改为~2.6.0, 执行composer install
此时，会发现版本号并没有变化
这是因为当我们第一次执行composer install，会生成composer.lock文件，这个文件记录了包的指定版本
当我们再次执行composer install时，?composer会先去composer.lock中检查有没有相应的包信息，如果有，以composer.lock的版本为准。如果我们要跳过composer.lock的限制，需要改用composer update指令
此时，我们看到，版本已经更新为2.6.1
最后再试下将版本号改为^2.6.0, 执行composer update
此时，已经更新到最新版本号
composer.lock锁文件composer.json在指定版本时，不一定是精确指定，很多时候是使用范围指定，只有当我们安装了包，才知道最终安装了哪个版本。那么问题来了，如果我们半年后再根据composer.json来安装包，可能有些包的版本已经升级了，且向下不兼容，这就有可能导致程序报错。为避免这种问题，在执行composer install之后，composer会生成composer.lock锁文件。
在锁文件中可以看到完整的包信息，包括包的版本号。
composer install命令会先检查锁文件是否存在，如果存在，它将下载composer.lock指定的版本（忽略 composer.json 文件中的定义）
如果在composer.json中修改了版本号，必须执行composer update命令，这个命令会根据composer.json的定义安装包，并更新composer.lock文件
锁文件非常重要！必须将composer.lock文件上传到代码仓库，这样才能保证团队各成员所安装的包版本是一致的。
composer通过create-project 可以直接创建一个完整的项目，将包所在的代码仓库clone下来
以创建laravel项目为例：
learnComposer composer create-project laravel/laravel Laravel --prefer-dist "5.5.*"
有些包我们仅需要在本地安装，生产环境并不需要，可以在composer.json中通过require-dev进行声明，如：
composer install --no-dev 会忽略require-dev所声明的包
composer install会将require-dev声明的包一并获取
在Laravel的composer.json文件中，有这么一段声明：
"scripts": {
"post-root-package-install": [
"@php -r \"file_exists(‘.env‘) || copy(‘.env.example‘, ‘.env‘);\""
],
"post-create-project-cmd": [
"@php artisan key:generate"
],
"post-autoload-dump": [
"Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
"@php artisan package:discover"
]
},
表示在执行composer install时的相应阶段，会自动触发运行脚本
composer.json文件在项目根目录执行composer init，生成composer.json配置文件
在packagist注册账号，然后登录。
提交github仓库地址
包创建成功
如果用的是国内的镜像，暂时还不能拉取，需要等国内镜像同步成功后才能拉取
如果要实现当github仓库代码更新就触发包的自动更新，需要进行以下设置
在github中添加packagist服务
自动同步需要用到packagist的Api token，查看token
提交配置
掌握以上的composer基础操作，在日常开发中已经足够使用。如果你是一个没怎么用过composer的php开发者，强烈推荐你从现在开始就用composer。在我看来，composer不仅仅是一个工具，而是联结php应用的生态，如果没有composer或类似的依赖管理工具，很难想象PHP还能保持活力。
标签：logger 令行 完整 upd 方便 服务 难度 大于 需要
原文地址：https://www.cnblogs.com/phpk/p/10929836.html
