在 PHP 代码的顶部你是不是经常看到这样的代码。

require 'lionis.php'; require 'is.php'; require 'cool.php';

如果只是引入几个 PHP 脚本，那还可以接受。那引入成千上万个脚本的时候，爆炸是在所难免的。如果对一个脚本改了个名字，还需要对引入改脚本的每个脚本改名，能不爆炸吗？连打出这段话都怎么绕。

电气时代

在 PHP 电气时代，开始出现了 __autoload 和 spl_autoload_register 函数注册自定义的自动加载策略。

通俗的来说， __autoload 和 spl_autoload_register 是一个 杀手组织 ，他们会去雇佣 各国杀手 ( 函数 )。当我们想搞定某个人的时候（ new ），只需要提供名字( 类名 )，剩下的 杀手 会帮我们搞定的。

__autoload

PHP 5 开始提供这个函数 传送门 。当你使用的 类 找不到的时候，它把类名当成参数扔进这个函数。

<?php // Lionis.php class Lionis { public function __construct() { echo '欧耶耶, 我就是 Lionis'; } } <?php // index.php function __autoload($classname) { $filename = './' . $classname . '.php'; require_once $filename; } $lionis = new Lionis();

输出

欧耶耶, 我就是 Lionis spl_autoload_register

如果我们 项目 很大很老又或者你是一个 爱折腾 的少先队员，需要引入的东西有不一样的规范，这时候如果都放在 __autoload 函数里，这个函数马上就会膨胀的。而且 __autoload 是全局唯一的，如果被人占用了，可能会导致错误。（欲使一个人灭亡，必将先使其膨胀。）

PHP 5.1.2 开始提供这个函数 传送门 ，注册给定的函数作为 __autoload 的实现。所以，我们看一些框架或插件在自己使用的时候，为了兼容可能会出现 function_exists(spl_autoload_register) 。

<?php function lionisIsCoolFind($classname) { require './' . $classname . '.php'; } // 函数 spl_autoload_register('lionisIsCoolFind'); // 匿名函数 spl_autoload_register(function($require) { require './' . $classname . '.php'; }); // 类中的函数 spl_autoload_register(array('Lionis', 'loadClass'));

欧耶，这下我们可以写很多不同的自动加载函数了。

信息时代

师傅小心，前面有妖气！ 。如果我们每个人都自己实现一套自动加载的方法，每个PHP 组件 和 框架 都使用独特的自动加载器，而且每个框架使用不同的逻辑加载PHP类、接口和性状。

那当我们使用一些第三方框架的时候，还需要去弄清楚引导文件中的 自动加载器 ，那样是有多和 时间 过不去呢。 PHP-FIG 认识到了这个问题了，推荐使用 PSR-4 规范，来促进组件之间的 互操作性 ，这样我们就可以使用一个自动加载器了。

PSR-4 规范

利用命名空间的前缀和文件系统中的目录对应起来。

映射关系为

namespace => filePath \Lionis\Cool => cool

带有命名空间的类

<?php // 该文件为 cool/Real.php namespace \Lionis\Cool; class Real { }

创建一个对象

<?php // 该文件为 index.php $lionis = new \Lionis\Cool\Real;

这个时候，按照 PSR-4 的规范，自动加载器应该去加载 cool/ 目录下的 Real.php 。

不对！ 那这样不是还要自己去实现 自动加载器 嘛，不然怎么 无中生有 出现 自动加载器 呢？难道官方 内置 了?

你 out 了吧，我们可以使用依赖管理器 composer 来生成 PSR-4 自动加载器。你可能会疑问，那我的旧项目没有遵循 PSR-4 规范怎么办？嘿嘿，让我们来探索发现一下 composer 是怎么解决这个问题的吧。

Composer

哦吼吼，我们这次的重点在与探究自动加载，所以 composer 的安装和使用等，就不去讨论了。

composer 自动加载设置了 4种 加载方式 ：

PSR-0

PSR-4

classmap

files

PSR-0

要求命名空间和目录层层对应，且可以使用 _ 作为路径分隔符，但是这会导致目录结果变得过深。

PHP 7, like Apache, is included in the Ubuntu archives. However, I was planning on using the PHP Apache module, and since I was building Apache from source, I figured there'd be a lot of hoops for me to jump through if I tried to shoehorn the .deb into working for me. Since building Apache modules is really pretty straight-forward, I just went straight for building the PHP Apache module from source, as a new part in the snapcraft.yaml . Of course, it uses the various Apache headers and tools for building modules, which is another part in the YAML, and that relationship is specified by using the after keyword in snapcraft, something like this:

# ...
parts:
apache:
plugin: apache
# ...
php:
plugin: autotools
after: [apache]
# ...
# ...

Using the after keyword like this tells snapcraft that the php part depends upon the apache part, and apache should be staged before php is built. However, going down this path quickly led me to:

Lesson 3: Project build systems aren't really prepared for snapcraft

This is pretty similar to Lesson 2 in the previous post in that the problem is the same, but the effect is different. As I mentioned in the previous post, Apache writes its prefix everywhere, including its tools for building modules (e.g. apxs ). This has the effect that modules built using apxs get installed into that same prefix . There doesn't seem to be any way to redirect it elsewhere.