我们都知道Composer是现代PHP框架（Yii2、Laravel...）的基石，有了Composer后我们开发是一件多么的爽的事情。
本文仅仅关注Composer的自动加载。
我们以Yii2为例，当我们通过Composer生成了一个Yii2程序后，会在vendor下建立一个autoload.php文件，它负责帮我们自动加载vendor内的各种库（yii2核心库也在vendor内，你懂得！）。
而你一定知道Yii2的入口文件index.php有一行。
require(__DIR__ . '/../vendor/autoload.php');由此可见，Yii2对Composer的友好程度，也难怪~孤木不成林，Yii2也要靠无数个Composer扩展枝干才能变成参天大树。
下面开始正式讲解Composer的autoload，告诉你各式各样扩展安装后，我们并没有使用include / require，那么Composer是如何帮我们找到他们的那？
目前为止,Composer一共支持4种自动加载方式
PSR-0
PSR-4
class-map
直接包含file
这四种方式足以让Composer涵盖地球上所有的PHP第三方扩展库。
PSR是一套PHP开发标准，现在大多数主流框架都在支持，工兵连已经开专题分享PSR干货。
PSR-4
PSR-4是Composer推荐使用的一种方式，因为它更易使用并能带来更简洁的目录结构。在一个扩展的composer.json里是这样进行配置的：
{
"autoload": {
"psr-4": {
"Foo\\": "src/",
}
}
}key和value就定义出了namespace以及其对应的目录映射。按照PSR-4的规则，当试图自动加载"Foo\Bar\Baz"类的使用，会去寻找"srcBarBaz.php"这个文件，如果它存在则加载，要注意的是此时"Foo\"并不会出现在文件路径中。
而composer.json这样的配置会被Composer转换成namespace与文件目录的MAP形式，并存在vendor/composer/autoload_psr4.php文件中，所以如果你安装的某个扩展自动加载是PSR-4形式，你可以在autoload_psr4.php找到它的真实路径。
PSR-0
这是一个已经过时的标准，那是在遥远的PHP5.2时代，你我都知道，PHP5.3之后才有了类似namespace这样的高级属性，所以PSR-0更多是考虑<=5.2时代的扩展，于是乎PSR组织用了一个伪namespace的做法。
有点蒙圈么？那我们来看代码你就明白了。
{
"autoload": {
"psr-0": {
"Foo\\": "src/",
}
}
}我们来分析这个扩展的加载方式，什么是伪namespace那？当我们用这个库的时候
$model = new Foo_Bar_Baz();对的，PSR-0的时代，有很多以下划线分隔的类名，它代表。。。它代表。。。
src/Foo/Bar/Baz.php聪明的你一定明白什么是伪namespace了吧，通过命名的下划线来映射目录结构。
哎，那个时代的标准制定者们也真心不容易呀。
Class-map方式
{
"autoload": {
"classmap": ["src/", "lib/"]
}
}这个加载方式比较容易理解，当Composer开始安装扩展的时候，会根据composer.json里的这个 autoload 告诉的方式classmap，来遍历src、lib目录然后将里面的类文件和其路径一一对应，存放到vendor/composer/autoload_classmap.php内。
例如src/下有一个BaseController类，那么在autoload_classmap.php文件中，就会生成这样的配置:
'BaseController' => $baseDir . '/src/BaseController.php'若你还不懂，去看看autoload_classmap.php吧。
File方式
有了上面这些加载方式还不够么? 是的，还会有一些供全局使用的比如帮助等这样函数，那么好吧，我们就讲这些文件直接包含进来好了。
{
"autoload": {
"files": ["src/MyLibrary/functions.php"]
}
}Composer安装扩展后会将其放到
vendor/composer/autoload_files.php到此刻，世界清静了，Composer可以加载我大PHP世界的各种库，只要你想，就可以自动加载。
原文链接 http://nai8.me/sapper-view.ht...