PHP 自動載入功能原理解析

leoyang發表於2017-05-11

前言

在開始之前，歡迎關注我自己的部落格： www.leoyang90.cn

本文已經所在 GitBook 地址：https://www.gitbook.com/book/leoyang90/lar...

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

一、PHP自動載入功能

PHP自動載入功能的由來

在 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機制的實現解析

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 呼叫堆疊，不同的對映關係寫到不同的 _autoload 函式中去，然後統一註冊統一管理，這個就是 PHP5 引入的 SPL Autoload。

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 思想，名稱空間在一定程度上算是類名的別名，那麼為什麼要推出名稱空間，名稱空間的優點是什麼呢

二、Namespace名稱空間

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

什麼是名稱空間？從廣義上來說，名稱空間是一種封裝事物的方法。在很多地方都可以見到這種抽象概念。例如，在作業系統中目錄用來將相關檔案分組，對於目錄中的檔案來說，它就扮演了名稱空間的角色。具體舉個例子，檔案 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 新特性系列（一） —— 名稱空間

三、PSR標準

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

PSR-0 (Autoloading Standard) 自動載入標準
PSR-1 (Basic Coding Standard)基礎編碼標準
PSR-2 (Coding Style Guide) 編碼風格嚮導
PSR-3 (Logger Interface) 日誌介面
PSR-4 (Improved Autoloading) 自動載入的增強版，可以替換掉PSR-0了。

具體詳細的規範標準可以檢視 PHP中PSR-[0-4]規範

PSR0標準

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 的分隔符(/)要轉換成 DIRECTORYSEPARATOR (作業系統路徑分隔符)
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 這個名稱空間轉為 \Symfony\Core\Request 這樣的目錄結構。

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

這句話的意思就是說，如果我們的名稱空間是 /Symfony/Core/Request_a，那麼我們就應該把它對映到 \Symfony\Core\Request\a 這樣的目錄。為什麼會有這種規定呢？這是因為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，這種目錄結構層次是不是太深了？

PSR4 標準

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_Name\Package_Name\ClassName
            tests/
                Vendor_Name/
                    Package_Name/
                        ClassNameTest.php   # Vendor_Name\Package_Name\ClassName

PSR-4 風格

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

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

本作品採用《CC 協議》，轉載必須註明作者和本文連結

PHP自動載入機制
2017-10-29
PHP
PHP 類自動載入機制
2016-06-14
PHP
php 自動類載入類 composer.json 實現自動載入
2021-07-20
PHPJSON
初學 PHP 類的自動載入
2018-10-23
PHP
Composer 自動載入原始碼解析
2019-05-31
原始碼
徹底搞懂Composer自動載入原理
2021-11-01
PHP 物件導向（八）類的自動載入
2020-01-18
PHP物件
PHP檔案的自動載入（autoloading）
2019-02-20
PHP
php匯入功能，模板下載
2020-11-04
PHP
Java類載入原理解析
2017-10-06
Java
php基礎，php自動載入的實現程式碼示例
2021-05-16
PHP
自動載入
2020-10-14
PHP 的自動載入（持續學習更新中）
2022-02-15
PHP
PHP名稱空間與自動載入簡述
2018-04-27
PHP
PHP AutoLoad 自動載入機制分析實踐
2015-03-05
PHP
PHP名稱空間及自動載入淺析
2015-03-13
PHP
PHP自動載入__autoload的工作機制
2015-05-20
PHP
webpack模組非同步載入原理解析
2019-12-29
Web非同步
SpringBoot自動配置原理解析
2023-11-02
Spring Boot
Composer 實現自動載入原理-新手也能看懂
2020-04-08
Composer 自動載入
2018-08-19
PHP名稱空間與PSR-4自動載入
2019-03-11
PHP
PHP PSR-4 Autoloader 自動載入(中文版)
2015-01-29
PHP
動態載入APK原理分享
2016-01-07
APK
滾動載入圖片（懶載入）實現原理
2019-04-06
SpringBoot自動裝配原理解析
2021-03-09
Spring Boot
SpringBoot原始碼解析-Bean的載入與自動化配置
2019-03-19
Spring Boot原始碼Bean
composer自動載入配置
2019-02-16
（十三）自動載入新模組
2018-01-17
APK動態載入框架（DL）解析
2015-08-17
APK框架
自動載入的iframe高度自適應
2021-09-09
PHP框架中的檔案載入的實現(自動載入/PSR規範/名稱空間)
2019-02-25
PHP框架
ThinkPHP6 的自動載入
2020-01-13
PHP
SpringBoot--自動載入
2017-11-18
Spring Boot
php手動載入檢視檔案
2017-11-12
PHP
PHP 手冊 (類與物件) 學習筆記四：類的自動載入
2020-06-01
PHP物件筆記
PHP檔案下載原理
2012-09-18
PHP
Laravel自動依賴解析的實現，其實是PHP對映解析
2021-07-04
LaravelPHP