thinkPHP5.0架構應用請求生命週期分析

這篇文章主要介紹了thinkPHP5.0架構應用請求生命週期,較為詳細的分析了thinkPHP5.0架構應用請求生命週期所涉及的各個執行流程,需要的朋友可以參考下

本文執行個體講述了thinkPHP5.0架構應用請求生命週期。分享給大家供大家參考，具體如下：

本篇內容我們對ThinkPHP5.0的應用請求的生命週期做大致的介紹，以便於開發人員瞭解整個執行流程。

1、入口檔案

使用者發起的請求都會經過應用的入口檔案，通常是 public/index.php檔案。當然，你也可以更改或者增加新的入口檔案。

通常入口檔案的代碼都比較簡單，一個普通的入口檔案代碼如下：

// 應用入口檔案// 定義項目路徑define('APP_PATH', __DIR__ . '/../application/');// 載入架構引導檔案require __DIR__ . '/../thinkphp/start.php';

一般入口檔案已定義一些常量為主，支援的常量請參考後續的內容或者附錄部分。

通常，我們不建議在應用入口檔案中加入過多的代碼，尤其是和商務邏輯相關的代碼。

2、引導檔案

接下來就是執行架構的引導檔案，start.php檔案就是系統預設的一個引導檔案。在引導檔案中，會依次執行下面操作：

① 載入系統常量定義；
② 載入環境變數定義檔案；
③ 註冊自動載入機制；
④ 註冊錯誤和異常處理機制；
⑤ 載入慣例設定檔；
⑥ 執行應用；

如果在你的應用入口檔案中更改了預設的引導檔案，則上述執行流程可能會跟隨發生變化。

3、註冊自動載入

系統會調用Loader::register()方法註冊自動載入，在這一步完成後，所有符合規範的類庫（包括Composer依賴載入的第三方類庫）都將自動載入。

系統的自動載入由兩個部分組成：

① 註冊系統的自動載入方法 \think\Loader::autoload
② 註冊系統命名空間定義
③ 載入類庫對應檔（如果存在）
④ 如果存在Composer安裝，則註冊Composer自動載入
⑤ 註冊Extend擴充目錄

一個類庫的自動載入檢測順序為：

① 是否定義類庫映射；
② PSR-4自動載入檢測；
③ PSR-0自動載入檢測；

可以看到，定義類庫映射的方式是最高效的。

4、註冊錯誤和異常機制

執行Error::register()註冊錯誤和異常處理機制。

由三部分組成：

① 應用關閉方法：think\Error::appShutdown
② 錯誤處理方法：think\Error::appError
③ 異常處理方法：think\Error::appException

註冊應用關閉方法是為了便於攔截一些系統錯誤。

在整個應用請求的生命週期過程中，如果拋出了異常或者嚴重錯誤，均會導致應用提前結束，並響應輸出異常和錯誤資訊。

5、應用初始化

執行應用的第一步操作就是對應用進行初始化，包括：

載入應用（公用）配置；
載入應用狀態配置；
載入別名定義；
載入行為定義；
載入公用（函數）檔案；
載入擴充設定檔（由extra_config_list定義）；
載入擴充函數檔案（由extra_file_list定義）；
設定預設時區；
載入系統語言套件；

6、URL訪問檢測

應用初始化完成後，就會進行URL的訪問檢測，包括PATH_INFO檢測和URL尾碼檢測。

5.0的URL訪問必須是PATH_INFO方式（包括相容方式）的URL地址，例如：

http://serverName/index.php/index/index/hello/val/value

所以，如果你的環境只能支援普通方式的URL參數訪問，那麼必須使用

http://serverName/index.php?s=/index/index/hello&val=value

如果是命令列下面訪問入口檔案的話，則通過

$php index.php index/index/hello/val/value...

擷取到正常的$_SERVER['PATH_INFO']參數後才能繼續。

7、路由檢測

如果開啟了url_route_on參數的話，會首先進行URL的路由檢測。

如果一旦檢測到匹配的路由，根據定義的路由地址會註冊到相應的URL調度。

5.0的路由地址支援如下方式：

路由到模組/控制器/操作；
路由到外部重新導向地址；
路由到控制器方法；
路由到閉包函數；
路由到類的方法；

路由地址可能會受網域名稱綁定的影響。

如果關閉路由或者路由檢測無效則進行預設的模組/控制器/操作的分析識別。

如果在應用初始化的時候指定了應用調度方式，那麼路由檢測是可選的。

可以使用 \think\App::dispatch() 進行應用調度。

8、分發請求

在完成了URL檢測和路由檢測之後，路由器會分發請求到對應的路由地址，這也是應用請求的生命週期中最重要的一個環節。

在這一步驟中，完成應用的商務邏輯及資料返回。

建議統一使用return返回資料，而不是echo輸出，如非必要，請不要執行exit中斷。

直接echo輸出的資料將無法進行自動轉換響應輸出的便利。

下面是系統支援的分發請求機制，可以根據情況選擇：

模組/控制器/操作

這是預設的分發請求機制，系統會根據URL或者路由地址來判斷當前請求的模組、控制器和操作名，並自動調用相應的存取控制器類，執行操作對應的方法。

該機制下面，首先會判斷當前模組，並進行模組的初始化操作（和應用的初始化操作類似），模組的配置參數會覆蓋應用的尚未生效的配置參數。

支援模組映射、URL參數綁定到方法，以及操作綁定到類等一些功能。

控制器方法

和前一種方式類似，只是無需判斷模組、控制器和操作，直接分發請求到一個指定的控制器類的方法，因此沒有進行模組的初始化操作。

外部重新導向

可以直接分發請求到一個外部的重新導向地址，支援指定重新導向代碼，預設為301重新導向。

閉包函數

路由地址定義的時候可以直接採用閉包函數，完成一些相對簡單的邏輯操作和輸出。

類的方法

除了以上方式外，還支援分發請求到類的方法，包括：
靜態方法：

'blog/:id'=>'\org\util\Blog::read'

類的方法：

'blog/:id'=>'\app\index\controller\Blog@read'

9、響應輸出

控制器的所有操作方法都是return返回而不是直接輸出，系統會調用Response::send方法將最終的應用返回的資料輸出到頁面或者用戶端，並自動轉換成default_return_type參數配置的格式。所以，應用執行的資料輸出只需要返回一個正常的PHP資料即可。

10、應用結束

事實上，在應用的資料響應輸出之後，應用並沒真正的結束，系統會在應用輸出或者中斷後進行日誌儲存寫入操作。

系統的日誌包括使用者調試輸出的和系統自動產生的日誌，統一會在應用結束的時候進行寫入操作。

而日誌的寫入操作受日誌初始化的影響。