摘要：前言在開始之前，歡迎關注我自己的博客這篇文章是對自動加載功能的一個總結，內容涉及的自動加載功能的命名空間的與標準等內容。要實現第一步，第二步的功能，必須在開發時約定類名與磁盤文件的映射方法，只有這樣我們才能根據類名找到它對應的磁盤文件。

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

這篇文章是對PHP自動加載功能的一個總結，內容涉及PHP的自動加載功能、PHP的命名空間、PHP的PSR0與PSR4標準等內容。

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

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

總結起來，自動加載功能帶來了幾處優點：

使用類之前無需 include 或者 require

使用類的時候才會 require/include 文件，實現了 lazy loading，避免了 require/include 多余文件。

無需考慮引入類的實際磁盤地址，實現了邏輯和實體文件的分離。

??
如果想具體詳細的了解關于自動加載的功能，可以查看資料：
PHP的類自動加載機制
PHP的autoload機制的實現解析

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

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

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

根據類名確定類文件名；

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

將類從磁盤文件中加載到系統中。

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

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

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

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

SPL是 Standard PHP Library (標準PHP庫)的縮寫。它是 PHP5 引入的一個擴展庫，其主要功能包括 autoload 機制的實現及包括各種 Iterator 接口或類。SPL Autoload 具體有幾個函數：

spl_autoload_register：注冊__autoload()函數

spl_autoload_unregister：注銷已注冊的函數

spl_autoload_functions：返回所有已注冊的函數

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

spl_autoload ：__autoload() 的默認實現

spl_autoload_extionsions： 注冊并返回 spl_autoload 函數使用的默認文件擴展名。

??
這幾個函數具體詳細用法可見 php中spl_autoload詳解

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

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

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

不過在談 PSR0 與 PSR4 之前，我們還需要了解 PHP 的命名空間的問題，因為這兩個標準其實針對的都不是類名與目錄文件的映射，而是命名空間與文件的映射。為什么會這樣呢？在我的理解中，規范的面向對象 PHP 思想，命名空間在一定程度上算是類名的別名，那么為什么要推出命名空間，命名空間的優點是什么呢

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

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

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

另外，命名空間提供了一種將相關的類、函數和常量組合到一起的途徑。這也是面向對象語言命名空間的很大用途，把特定用途所需要的類、變量、函數寫到一個命名空間中，進行封裝。

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

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

具體詳細的規范標準可以查看
PHP中PSR規范

PRS-0規范是他們出的第1套規范，主要是制定了一些自動加載標準（Autoloading Standard）PSR-0 強制性要求幾點：

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

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

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

??
好了，我們先想一想，對于一個具體程序來說，如果它想要支持PSR0標準,它需要做什么調整呢？

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

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

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

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

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

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

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

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

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

??

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

現在我們終于來到了映射規范了。命名空間的/符號要轉為路徑分隔符，也就是說要把 /Symfony/Core/Request 這個命名空間轉為 SymfonyCoreRequest 這樣的目錄結構。
??

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

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

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

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

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

按照 PSR0 標準，命名空間 /A/B/C/D/E/F 必然對應一個目錄結構 /A/B/C/D/E/F，這種目錄結構層次是不是太深了？

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

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

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

命名空間與文件目錄的映射方法有所調整。

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

"Foo/" => "src/"

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

再舉一個例子,來源 PSR-4——新鮮出爐的PHP規范：
PSR-0風格

    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風格

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

對比以上兩種結構，明顯可以看出PSR-4帶來更簡潔的文件結構。

Written with StackEdit.