我们都知道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://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。