本篇內容我們對ThinkPHP`5.0`的應用請求的生命周期做大致的介紹，以便于開發者了解整個執行流程。 ## 1、入口文件 用戶發起的請求都會經過應用的入口文件，通常是 `public/index.php`文件。當然，你也可以更改或者增加新的入口文件。 通常入口文件的代碼都比較簡單，一個普通的入口文件代碼如下： ~~~ // 應用入口文件 // 定義項目路徑 define('APP_PATH', __DIR__ . '/../application/'); // 加載框架引導文件 require __DIR__ . '/../thinkphp/start.php'; ~~~ 一般入口文件以定義一些常量為主，支持的常量請參考后續的內容或者附錄部分。 > 通常，我們不建議在應用入口文件中加入過多的代碼，尤其是和業務邏輯相關的代碼。 ## 2、引導文件 接下來就是執行框架的引導文件，`start.php`文件就是系統默認的一個引導文件。在引導文件中，會依次執行下面操作： * 加載系統常量定義； * 加載環境變量定義文件； * 注冊自動加載機制； * 注冊錯誤和異常處理機制； * 加載慣例配置文件； * 執行應用； `start.php`引導文件首先會調用`base.php`基礎引導文件，某些特殊需求下面可能直接在入口文件中引入基礎引導文件。 > 如果在你的應用入口文件中更改了默認的引導文件，則上述執行流程可能會跟隨發生變化。 ## 3、注冊自動加載 系統會調用 `Loader::register()`方法注冊自動加載，在這一步完成后，所有符合規范的類庫（包括`Composer`依賴加載的第三方類庫）都將自動加載。 系統的自動加載由下面主要部分組成： 1. 注冊系統的自動加載方法 **`\think\Loader::autoload`** 2. 注冊系統命名空間定義 3. 加載類庫映射文件（如果存在） 4. 如果存在`Composer`安裝，則注冊**`Composer`**自動加載 5. 注冊`extend`擴展目錄 一個類庫的自動加載檢測順序為： 1. 是否定義類庫映射； 2. `PSR-4`自動加載檢測； 3. `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() 進行應用調度，例如： App::dispatch(['type' => 'module', 'module' => 'index/index']); ## 8、分發請求 在完成了URL檢測和路由檢測之后，路由器會分發請求到對應的路由地址，這也是應用請求的生命周期中最重要的一個環節。 在這一步驟中，完成應用的業務邏輯及數據返回。 建議統一使用`return`返回數據，而不是`echo`輸出，如非必要，請不要使用`exit`或者`die`中斷執行。 > 直接`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、應用結束 事實上，在應用的數據響應輸出之后，應用并沒真正的結束，系統會在應用輸出或者中斷后進行日志保存寫入操作。 系統的日志包括用戶調試輸出的和系統自動生成的日志，統一會在應用結束的時候進行寫入操作。 而日志的寫入操作受日志初始化的影響。