摘要：前言在開始之前，歡迎關(guān)注我自己的博客這篇文章是對自動加載功能的一個總結(jié)，內(nèi)容涉及的自動加載功能的命名空間的與標(biāo)準(zhǔn)等內(nèi)容。要實(shí)現(xiàn)第一步，第二步的功能，必須在開發(fā)時約定類名與磁盤文件的映射方法，只有這樣我們才能根據(jù)類名找到它對應(yīng)的磁盤文件。

在開始之前，歡迎關(guān)注我自己的博客：www.leoyang90.cn

這篇文章是對PHP自動加載功能的一個總結(jié)，內(nèi)容涉及PHP的自動加載功能、PHP的命名空間、PHP的PSR0與PSR4標(biāo)準(zhǔn)等內(nèi)容。

在PHP開發(fā)過程中，如果希望從外部引入一個 class，通常會使用 include 和 require 方法，去把定義這個 class 的文件包含進(jìn)來。這個在小規(guī)模開發(fā)的時候，沒什么大問題。但在大型的開發(fā)項(xiàng)目中，使用這種方式會帶來一些隱含的問題：如果一個 PHP 文件需要使用很多其它類，那么就需要很多的 require/include 語句，這樣有可能會造成遺漏或者包含進(jìn)不必要的類文件。如果大量的文件都需要使用其它的類，那么要保證每個文件都包含正確的類文件肯定是一個噩夢， 況且 require_once 的代價很大。

PHP5 為這個問題提供了一個解決方案，這就是類的自動裝載 (autoload) 機(jī)制。autoload 機(jī)制可以使得 PHP 程序有可能在使用類時才自動包含類文件，而不是一開始就將所有的類文件 include 進(jìn)來，這種機(jī)制也稱為 lazy loading。

總結(jié)起來，自動加載功能帶來了幾處優(yōu)點(diǎn)：

使用類之前無需 include 或者 require

使用類的時候才會 require/include 文件，實(shí)現(xiàn)了 lazy loading，避免了 require/include 多余文件。

無需考慮引入類的實(shí)際磁盤地址，實(shí)現(xiàn)了邏輯和實(shí)體文件的分離。

??
如果想具體詳細(xì)的了解關(guān)于自動加載的功能，可以查看資料：
PHP的類自動加載機(jī)制
PHP的autoload機(jī)制的實(shí)現(xiàn)解析

通常 PHP5 在使用一個類時，如果發(fā)現(xiàn)這個類沒有加載，就會自動運(yùn)行 _autoload() 函數(shù)，這個函數(shù)是我們在程序中自定義的，在這個函數(shù)中我們可以加載需要使用的類。下面是個簡單的示例：

function __autoload($classname) {
    require_once ($classname . "class.php"); 
}

在我們這個簡單的例子中，我們直接將類名加上擴(kuò)展名 ”.class.php” 構(gòu)成了類文件名，然后使用 require_once 將其加載。從這個例子中，我們可以看出 autoload 至少要做三件事情：

根據(jù)類名確定類文件名；

確定類文件所在的磁盤路徑(在我們的例子是最簡單的情況，類與調(diào)用它們的PHP程序文件在同一個文件夾下)；

將類從磁盤文件中加載到系統(tǒng)中。

?
第三步最簡單，只需要使用 include/require 即可。要實(shí)現(xiàn)第一步，第二步的功能，必須在開發(fā)時約定類名與磁盤文件的映射方法，只有這樣我們才能根據(jù)類名找到它對應(yīng)的磁盤文件。

當(dāng)有大量的類文件要包含的時候，我們只要確定相應(yīng)的規(guī)則，然后在 __autoload() 函數(shù)中，將類名與實(shí)際的磁盤文件對應(yīng)起來，就可以實(shí)現(xiàn) lazy loading 的效果。從這里我們也可以看出 _autoload() 函數(shù)的實(shí)現(xiàn)中最重要的是類名與實(shí)際的磁盤文件映射規(guī)則的實(shí)現(xiàn)。

如果在一個系統(tǒng)的實(shí)現(xiàn)中，如果需要使用很多其它的類庫，這些類庫可能是由不同的開發(fā)人員編寫的，其類名與實(shí)際的磁盤文件的映射規(guī)則不盡相同。這時如果要實(shí)現(xiàn)類庫文件的自動加載，就必須在 __autoload() 函數(shù)中將所有的映射規(guī)則全部實(shí)現(xiàn)，這樣的話 autoload() 函數(shù)有可能會非常復(fù)雜，甚至無法實(shí)現(xiàn)。最后可能會導(dǎo)致 autoload() 函數(shù)十分臃腫，這時即便能夠?qū)崿F(xiàn)，也會給將來的維護(hù)和系統(tǒng)效率帶來很大的負(fù)面影響。

那么問題出現(xiàn)在哪里呢？問題出現(xiàn)在 _autoload() 是全局函數(shù)只能定義一次，不夠靈活，所以所有的類名與文件名對應(yīng)的邏輯規(guī)則都要在一個函數(shù)里面實(shí)現(xiàn)，造成這個函數(shù)的臃腫。那么如何來解決這個問題呢？答案就是使用一個 _autoload 調(diào)用堆棧，不同的映射關(guān)系寫到不同的 _autoload 函數(shù)中去，然后統(tǒng)一注冊統(tǒng)一管理，這個就是 PHP5 引入的 SPL Autoload。

SPL是 Standard PHP Library (標(biāo)準(zhǔn)PHP庫)的縮寫。它是 PHP5 引入的一個擴(kuò)展庫，其主要功能包括 autoload 機(jī)制的實(shí)現(xiàn)及包括各種 Iterator 接口或類。SPL Autoload 具體有幾個函數(shù)：

spl_autoload_register：注冊__autoload()函數(shù)

spl_autoload_unregister：注銷已注冊的函數(shù)

spl_autoload_functions：返回所有已注冊的函數(shù)

spl_autoload_call：嘗試所有已注冊的函數(shù)來加載類

spl_autoload ：__autoload() 的默認(rèn)實(shí)現(xiàn)

spl_autoload_extionsions： 注冊并返回 spl_autoload 函數(shù)使用的默認(rèn)文件擴(kuò)展名。

??
這幾個函數(shù)具體詳細(xì)用法可見 php中spl_autoload詳解

簡單來說，spl_autoload 就是 SPL 自己的定義 __autoload() 函數(shù)，功能很簡單，就是去注冊的目錄(由 set_include_path 設(shè)置)找與 $classname 同名的 .php/.inc 文件。當(dāng)然，你也可以指定特定類型的文件，方法是注冊擴(kuò)展名 (spl_autoload_extionsions)。

而 spl_autoload_register() 就是我們上面所說的 autoload 調(diào)用堆棧，我們可以向這個函數(shù)注冊多個我們自己的 _autoload() 函數(shù)，當(dāng) PHP 找不到類名時，PHP 就會調(diào)用這個堆棧，一個一個去調(diào)用自定義的 _autoload() 函數(shù)，實(shí)現(xiàn)自動加載功能。如果我們不向這個函數(shù)輸入任何參數(shù)，那么就會注冊 spl_autoload() 函數(shù)。

好啦，PHP 自動加載的底層就是這些，注冊機(jī)制已經(jīng)非常靈活，但是還缺什么呢？我們上面說過，自動加載關(guān)鍵就是類名和文件的映射，這種映射關(guān)系不同框架有不同方法，非常靈活，但是過于靈活就會顯得雜亂，PHP 有專門對這種映射關(guān)系的規(guī)范，那就是 PSR 標(biāo)準(zhǔn)中 PSR0 與 PSR4。

不過在談 PSR0 與 PSR4 之前，我們還需要了解 PHP 的命名空間的問題，因?yàn)檫@兩個標(biāo)準(zhǔn)其實(shí)針對的都不是類名與目錄文件的映射，而是命名空間與文件的映射。為什么會這樣呢？在我的理解中，規(guī)范的面向?qū)ο?PHP 思想，命名空間在一定程度上算是類名的別名，那么為什么要推出命名空間，命名空間的優(yōu)點(diǎn)是什么呢

要了解命名空間，首先先看看 官方文檔 中對命名空間的介紹：

什么是命名空間？從廣義上來說，命名空間是一種封裝事物的方法。在很多地方都可以見到這種抽象概念。例如，在操作系統(tǒng)中目錄用來將相關(guān)文件分組，對于目錄中的文件來說，它就扮演了命名空間的角色。具體舉個例子，文件 foo.txt 可以同時在目錄 /home/greg 和 /home/other 中存在，但在同一個目錄中不能存在兩個 foo.txt 文件。另外，在目錄 /home/greg 外訪問 foo.txt 文件時，我們必須將目錄名以及目錄分隔符放在文件名之前得到 /home/greg/foo.txt。這個原理應(yīng)用到程序設(shè)計(jì)領(lǐng)域就是命名空間的概念。
在PHP中，命名空間用來解決在編寫類庫或應(yīng)用程序時創(chuàng)建可重用的代碼如類或函數(shù)時碰到的兩類問題：
1 用戶編寫的代碼與PHP內(nèi)部的類/函數(shù)/常量或第三方類/函數(shù)/常量之間的名字沖突
2 為很長的標(biāo)識符名稱(通常是為了緩解第一類問題而定義的)創(chuàng)建一個或簡短）的名稱，提高源代碼的可讀性。
PHP 命名空間提供了一種將相關(guān)的類、函數(shù)和常量組合到一起的途徑。

??
簡單來說就是 PHP 是不允許程序中存在兩個名字一樣一樣的類或者函數(shù)或者變量名的，那么有人就很疑惑了，那就不起一樣名字不就可以了？事實(shí)上很多大程序依賴很多第三方庫，名字沖突什么的不要太常見，這個就是官網(wǎng)中的第一個問題。那么如何解決這個問題呢？在沒有命名空間的時候，可憐的程序員只能給類名起 a_b_c_d_e_f 這樣的，其中 a/b/c/d/e/f 一般有其特定意義，這樣一般就不會發(fā)生沖突了，但是這樣長的類名編寫起來累，讀起來更是難受。因此 PHP5 就推出了命名空間，類名是類名，命名空間是命名空間，程序?qū)?/ 看的時候直接用類名，運(yùn)行起來機(jī)器看的是命名空間，這樣就解決了問題。

另外，命名空間提供了一種將相關(guān)的類、函數(shù)和常量組合到一起的途徑。這也是面向?qū)ο笳Z言命名空間的很大用途，把特定用途所需要的類、變量、函數(shù)寫到一個命名空間中，進(jìn)行封裝。

解決了類名的問題，我們終于可以回到 PSR 標(biāo)準(zhǔn)來了，那么 PSR0 與 PSR4 是怎么規(guī)范文件與命名空間的映射關(guān)系的呢？答案就是：對命名空間的命名（額，有點(diǎn)繞）、類文件目錄的位置和兩者映射關(guān)系做出了限制，這個就是標(biāo)準(zhǔn)的核心了。更完整的描述可見 現(xiàn)代 PHP 新特性系列（一） —— 命名空間

在說 PSR0 與 PSR4 之前先介紹一下 PSR 標(biāo)準(zhǔn)。PSR 標(biāo)準(zhǔn)的發(fā)明者和規(guī)范者是：PHP-FIG，它的網(wǎng)站是：www.php-fig.org。就是這個聯(lián)盟組織發(fā)明和創(chuàng)造了 PSR 規(guī)范。FIG 是 Framework Interoperability Group（框架可互用性小組）的縮寫，由幾位開源框架的開發(fā)者成立于 2009 年，從那開始也選取了很多其他成員進(jìn)來，雖然不是 “官方” 組織，但也代表了社區(qū)中不小的一塊。組織的目的在于：以最低程度的限制，來統(tǒng)一各個項(xiàng)目的編碼規(guī)范，避免各家自行發(fā)展的風(fēng)格阻礙了程序設(shè)計(jì)師開發(fā)的困擾，于是大伙發(fā)明和總結(jié)了 PSR，PSR 是 Proposing a Standards Recommendation（提出標(biāo)準(zhǔn)建議）的縮寫。

具體詳細(xì)的規(guī)范標(biāo)準(zhǔn)可以查看
PHP中PSR規(guī)范

PRS-0規(guī)范是他們出的第1套規(guī)范，主要是制定了一些自動加載標(biāo)準(zhǔn)（Autoloading Standard）PSR-0 強(qiáng)制性要求幾點(diǎn)：

1、  一個完全合格的 namespace 和 class 必須符合這樣的結(jié)構(gòu)：“< Vendor Name>(< Namespace>)*< Class Name>”
2、每個 namespace 必須有一個頂層的 namespace（"Vendor Name" 提供者名字）
3、每個 namespace 可以有多個子 namespace
4、當(dāng)從文件系統(tǒng)中加載時，每個 namespace 的分隔符(/)要轉(zhuǎn)換成  DIRECTORY_SEPARATOR (操作系統(tǒng)路徑分隔符)
5、在類名中，每個下劃線(_)符號要轉(zhuǎn)換成 DIRECTORY_SEPARATOR (操作系統(tǒng)路徑分隔符)。在 namespace 中，下劃線_符號是沒有（特殊）意義的。
6、當(dāng)從文件系統(tǒng)中載入時，合格的 namespace 和 class 一定是以 .php 結(jié)尾的
7、verdor name,namespaces,class 名可以由大小寫字母組合而成（大小寫敏感的）

??
具體規(guī)則可能有些讓人暈，我們從頭講一下。
??
我們先來看PSR0標(biāo)準(zhǔn)大致內(nèi)容，第1、2、3、7條對命名空間的名字做出了限制，第4、5條對命名空間和文件目錄的映射關(guān)系做出了限制，第6條是文件后綴名。
??
前面我們說過，PSR標(biāo)準(zhǔn)是如何規(guī)范命名空間和所在文件目錄之間的映射關(guān)系？是通過限制命名空間的名字、所在文件目錄的位置和兩者映射關(guān)系。
??
那么我們可能就要問了，哪里限制了文件所在目錄的位置了呢？其實(shí)答案就是：
??

限制命名空間名字 + 限制命名空間名字與文件目錄映射 = 限制文件目錄

??
好了，我們先想一想，對于一個具體程序來說，如果它想要支持PSR0標(biāo)準(zhǔn),它需要做什么調(diào)整呢？

首先，程序必須定義一個符合PSR0標(biāo)準(zhǔn)第4、5條的映射函數(shù)，然后把這個函數(shù)注冊到 spl_register() 中；

其次，定義一個新的命名空間時，命名空間的名字和所在文件的目錄位置必須符合第1、2、3、7條。

??
一般為了代碼維護(hù)方便，我們會在一個文件只定義一個命名空間。
??
好了，我們有了符合PSR0的命名空間的名字，通過符合PSR0標(biāo)準(zhǔn)的映射關(guān)系就可以得到符合PSR0標(biāo)準(zhǔn)的文件目錄地址，如果我們按照PSR0標(biāo)準(zhǔn)正確存放文件，就可以順利require該文件了，我們就可以使用該命名空間啦，是不是很神奇呢？
??
接下來，我們詳細(xì)地來看看PSR0標(biāo)準(zhǔn)到底規(guī)范了什么呢？
??
我們以 laravel 中第三方庫Symfony其中一個命名空間 /Symfony/Core/Request 為例，講一講上面 PSR0 標(biāo)準(zhǔn)。
??

一個完全合格的 namespace 和 class 必須符合這樣的結(jié)構(gòu)：“< Vendor Name>(< Namespace>)*< Class Name>”

上面所展示的 /Symfony 就是 Vendor Name，也就是第三方庫的名字，/Core 是 Namespace 名字，一般是我們命名空間的一些屬性信息(例如 request 是 Symfony 的核心功能)；最后 Request 就是我們命名空間的名字，這個標(biāo)準(zhǔn)規(guī)范就是讓人看到命名空間的來源、功能非常明朗，有利于代碼的維護(hù)。
??

2 . 每個 namespace 必須有一個頂層的 namespace（"Vendor Name" 提供者名字）

也就是說每個命名空間都要有一個類似于 /Symfony 的頂級命名空間，為什么要有這種規(guī)則呢？因?yàn)?PSR0 標(biāo)準(zhǔn)只負(fù)責(zé)頂級命名空間之后的映射關(guān)系，也就是 /Symfony/Core/Request 這一部分，關(guān)于 /Symfony 應(yīng)該關(guān)聯(lián)到哪個目錄，那就是用戶或者框架自己定義的了。所謂的頂層的 namespace，就是自定義了映射關(guān)系的命名空間，一般就是提供者名字（第三方庫的名字）。換句話說頂級命名空間是自動加載的基礎(chǔ)。為什么標(biāo)準(zhǔn)要這么設(shè)置呢？原因很簡單，如果有個命名空間是 /Symfony/Core/Transport/Request，還有個命名空間是 /Symfony/Core/Transport/Request1,如果沒有頂級命名空間，我們就得寫兩個路徑和這兩個命名空間相對應(yīng)，如果再有 Request2、Request3 呢。有了頂層命名空間 /Symfony，那我們就僅僅需要一個目錄對應(yīng)即可，剩下的就利用 PSR 標(biāo)準(zhǔn)去解析就行了。
??

3.每個namespace可以有多個子namespace

這個很簡單，Request 可以定義成 /Symfony/Core/Request，也可以定義成 /Symfony/Core/Transport/Request，/Core 這個命名空間下面可以有很多子命名空間，放多少層命名空間都是自己定義。

??

4.當(dāng)從文件系統(tǒng)中加載時，每個 namespace 的分隔符(/)要轉(zhuǎn)換成  DIRECTORY_SEPARATOR (操作系統(tǒng)路徑分隔符)

現(xiàn)在我們終于來到了映射規(guī)范了。命名空間的/符號要轉(zhuǎn)為路徑分隔符，也就是說要把 /Symfony/Core/Request 這個命名空間轉(zhuǎn)為 SymfonyCoreRequest 這樣的目錄結(jié)構(gòu)。
??

5.在類名中，每個下劃線 _ 符號要轉(zhuǎn)換成 DIRECTORYSEPARATOR (操作系統(tǒng)路徑分隔符)。在 namespace 中，下劃線符號是沒有（特殊）意義的。

這句話的意思就是說，如果我們的命名空間是 /Symfony/Core/Request_a，那么我們就應(yīng)該把它映射到 SymfonyCoreRequesta 這樣的目錄。為什么會有這種規(guī)定呢？這是因?yàn)?PHP5 之前并沒有命名空間，程序員只能把名字起成 Symfony_Core_Request_a 這樣， PSR0 的這條規(guī)定就是為了兼容這種情況。
剩下兩個很簡單就不說了。
??
有這樣的命名空間命名規(guī)則和映射標(biāo)準(zhǔn)，我們就可以推理出我們應(yīng)該把命名空間所在的文件該放在哪里了。依舊以 Symfony/Core/Request 為例， 它的目錄是 /path/to/project/vendor/Symfony/Core/Request.php，其中 /path/to/project是你項(xiàng)目在磁盤的位置，/path/to/project/vendor 是項(xiàng)目用的所有第三方庫所在目錄。/path/to/project/vendor/Symfony 就是與頂級命名空間 /Symfony 存在對應(yīng)關(guān)系的目錄，再往下的文件目錄就是按照PSR0標(biāo)準(zhǔn)建立的：

/Symfony/Core/Request  =>  /Symfony/Core/Request.php

一切很完滿了是嗎？不，還有一些瑕疵：

我們是否應(yīng)該還兼容沒有命名空間的情況呢？

按照 PSR0 標(biāo)準(zhǔn)，命名空間 /A/B/C/D/E/F 必然對應(yīng)一個目錄結(jié)構(gòu) /A/B/C/D/E/F，這種目錄結(jié)構(gòu)層次是不是太深了？

2013年底，新出了第5個規(guī)范——PSR-4。

PSR-4規(guī)范了如何指定文件路徑從而自動加載類定義，同時規(guī)范了自動加載文件的位置。這個乍一看和 PSR-0 重復(fù)了，實(shí)際上，在功能上確實(shí)有所重復(fù)。區(qū)別在于 PSR-4 的規(guī)范比較干凈，去除了兼容 PHP 5.3 以前版本的內(nèi)容，有一點(diǎn) PSR-0 升級版的感覺。當(dāng)然，PSR-4 也不是要完全替代 PSR-0，而是在必要的時候補(bǔ)充 PSR-0 ——當(dāng)然，如果你愿意，PSR-4 也可以替代 PSR-0。PSR-4 可以和包括 PSR-0 在內(nèi)的其他自動加載機(jī)制共同使用。
??
PSR4標(biāo)準(zhǔn)與PSR0標(biāo)準(zhǔn)的區(qū)別：

在類名中使用下劃線沒有任何特殊含義。

命名空間與文件目錄的映射方法有所調(diào)整。

對第二項(xiàng)我們詳細(xì)解釋一下 ( Composer自動加載的原理)：
假如我們有一個命名空間：Foo/class，F(xiàn)oo 是頂級命名空間，其存在著用戶定義的與目錄的映射關(guān)系：

"Foo/" => "src/"

按照PSR0標(biāo)準(zhǔn)，映射后的文件目錄是: src/Foo/class.php，但是按照 PSR4 標(biāo)準(zhǔn)，映射后的文件目錄就會是:src/class.php，為什么要這么更改呢？原因就是怕命名空間太長導(dǎo)致目錄層次太深，使得命名空間和文件目錄的映射關(guān)系更加靈活。

再舉一個例子,來源 PSR-4——新鮮出爐的PHP規(guī)范：
PSR-0風(fēng)格

    vendor/
    vendor_name/
        package_name/
            src/
                Vendor_Name/
                    Package_Name/
                        ClassName.php       # Vendor_NamePackage_NameClassName
            tests/
                Vendor_Name/
                    Package_Name/
                        ClassNameTest.php   # Vendor_NamePackage_NameClassName

??PSR-4風(fēng)格

    vendor/
    vendor_name/
        package_name/
            src/
                ClassName.php       # Vendor_NamePackage_NameClassName
            tests/
                ClassNameTest.php   # Vendor_NamePackage_NameClassNameTest

對比以上兩種結(jié)構(gòu)，明顯可以看出PSR-4帶來更簡潔的文件結(jié)構(gòu)。

Written with StackEdit.