现代PHP应较少使用庞大的框架，而应该更多地使用具有互操作性的专业组件定制解决方案。
组件是神马？
组件是打包的代码，用于快速解决PHP应用中某个具体的问题。严格来说，PHP组件是一系列相关的类、接口、性状，用于解决某特定问题，而组件中类、接口、性状常位于同一个命名空间中。
组件原则
- 功能单一：一个组件解决一个问题
- 小巧玲珑：以最少的代码解决问题
- 互操作性：组件间良好和合作，各自命名空间防止命名冲突。
- 测试良好：自身提供测试且有充足的测试覆盖度
- 文档完善：标准README.md文件
组件 VS 框架
选择框架时，基于的心理是看中框架的未来，相信框架的核心开发团队，假定他们会投入时间更新，以确保紧跟现代标准。谁能保证某框架时完成某项工作最好的工具呢？现代的框架其实只是构建在小型组件之上的一系列约定。
使用框架还是框架呢？使用正确的工具做正确的事...
查找组件
https://github.com/ziadoz/awesome-php
使用组件
Packagist 是查找PHP组件的地方，Composer是安装PHP组件的工具，是PHP组件的依赖管理器，它能解析并下载组件的依赖。
安装Composer
# 下载composer安装脚本composer.phar文件
$ curl -sS https://getcomposer.org/installer | php
# 移动并重命名composer二进制文件
$ sudo mv composer.phar /usr/local/bin/composer
# 授权可执行的二进制文件
$ sudo chmod +x /usr/local/bin/composer
# 加入环境变量
$ vim ~/.bash_profile
PATH=/usr/local/bin:$PATH
组件命名
PHP组件名称由厂商名和包名构成，厂商名全局唯一是全局标识符，用于识别名下的包属于谁。包名用于唯一识别指定厂商下的包。
Composer和Packagist使用 vendor/package 命名约定以避免不同厂商的PHP组件命名冲突。
组件版本
现代PHP组件使用语义版本方案，版本号由三个点分数组组成。
x.y.z
x 第一个数字为主版本号，若更新破坏了向后兼容性，则会提升主版本号。
y 第二个数字为次版本号，若组件小幅更新了功能且没破坏向后兼容性，则会提升次版本号。
z 第三个数字为修订版本号，若组件修正了向后兼容的缺陷，会提升修订版本号。
让 Composer查找并安装指定PHP组件的最新稳定版
# 更新到下一个主版本之前的最新版
$ composer require vendor/package
执行的结果是在项目中创建或更新 composer.json 和 composer.lock 文件，这两个文件都要纳入版本控制系统。
composer.lock
composer.lock 列出项目使用的所有PHP组件以及具体版本号，目的是为了锁定项目中PHP的版本。将 composer.lock 纳入版本控制，将其分发给团队成员，使其使用的PHP组件版本一致，以降低由组件版本差异导致缺陷的风险。
composer.lock 的缺点在于，使用 composer install 不会比其中版本新的版本。
自动加载组件
Composer下载PHP组件时会为项目所有依赖创建一个符合PSR标准的加载器，使用时仅需在文件顶部导入即
可。
<?php
require 'vendor/autoload.php'
Composer私有仓库
Composer 可管理放在需要认证的仓库中的私有PHP组件，执行 composer install 获取 composer update，若组件仓库需认证凭据，composer会提醒并询问是否把认证凭证保存到本地的 auth.json 文件中，auto.json不能纳入版本仓库
auto.json
{
"http-basic":{
"example.org":{
"username":"username",
"password":"password"
}
}
}
若无需composer询问认证凭据，可为指定的域名添加认证。
# http-basic 告知composer为指定域名添加认证信息
# example.org 是主机名，用于识别存储私有仓库的远程设备。
# --global 标识系统全局保存认证凭证，可选。
$ composer config --global http-basic.example.org username password
