[TOC] # 啟動Laravel基礎服務 我們不妨再詳細一點： 第一步注冊加載composer自動生成的class loader就是加載初始化第三方依賴，不屬于Laravel核心，到此為止。 第二步生成容器Container，并向容器注冊核心組件，這里牽涉到了容器Container和合同Contracts，這是Laravel的重點，下面將詳細講解。 重點是第三步處理請求，生成并發送響應。 首先Laravel框架捕獲到用戶發到public\index.php的請求，生成Illuminate\Http\Request實例，傳遞給這個小小的handle方法。在方法內部，將該$request實例綁定到第二步生成的$app容器上。然后在該請求真正處理之前，調用bootstrap方法，進行必要的加載和注冊，如檢測環境，加載配置，注冊Facades（假象），注冊服務提供者，啟動服務提供者等等。這是一個啟動數組，具體在Illuminate\Foundation\Http\Kernel中，包括： ~~~ protected $bootstrappers = [ 'Illuminate\Foundation\Bootstrap\DetectEnvironment', 'Illuminate\Foundation\Bootstrap\LoadConfiguration', 'Illuminate\Foundation\Bootstrap\ConfigureLogging', 'Illuminate\Foundation\Bootstrap\HandleExceptions', 'Illuminate\Foundation\Bootstrap\RegisterFacades', 'Illuminate\Foundation\Bootstrap\RegisterProviders', 'Illuminate\Foundation\Bootstrap\BootProviders', ]; ~~~ 看類名知意，Laravel是按順序遍歷執行注冊這些基礎服務的，注意順序：Facades先于ServiceProviders，Facades也是重點，后面說，這里簡單提一下，注冊Facades就是注冊config\app.php中的aliases 數組，你使用的很多類，如Auth，Cache,DB等等都是Facades；而ServiceProviders的register方法永遠先于boot方法執行，以免產生boot方法依賴某個實例而該實例還未注冊的現象。 所以，你可以在ServiceProviders的register方法中使用任何Facades，在ServiceProviders的boot方法中使用任何register方法中注冊的實例或者Facades，這樣絕不會產生依賴某個類而未注冊的現象 # 將請求傳遞給路由 注意到目前為止，Laravel 還沒有執行到你所寫的主要代碼（ServiceProviders中的除外），因為還沒有將請求傳遞給路由。 在Laravel基礎的服務啟動之后，就要把請求傳遞給路由了。傳遞給路由是通過Pipeline（另開篇章講解）來傳遞的，但是Pipeline有一堵墻，在傳遞給路由之前所有請求都要經過，這堵墻定義在app\Http\Kernel.php中的$middleware數組中，沒錯就是中間件，默認只有一個CheckForMaintenanceMode中間件，用來檢測你的網站是否暫時關閉。這是一個全局中間件，所有請求都要經過，你也可以添加自己的全局中間件。 然后遍歷所有注冊的路由，找到最先符合的第一個路由，經過它的路由中間件，進入到控制器或者閉包函數，執行你的具體邏輯代碼。 所以，在請求到達你寫的代碼之前，Laravel已經做了大量工作，請求也經過了千難萬險，那些不符合或者惡意的的請求已被Laravel隔離在外  # 服務容器 服務容器就是一個普通的容器，用來裝類的實例，然后在需要的時候再取出來。用更專業的術語來說是服務容器實現了控制反轉（Inversion of Control，縮寫為IoC），意思是正常情況下類A需要一個類B的時候，我們需要自己去new類B，意味著我們必須知道類B的更多細節，比如構造函數，隨著項目的復雜性增大，這種依賴是毀滅性的。控制反轉的意思就是，將類A主動獲取類B的過程顛倒過來變成被動，類A只需要聲明它需要什么，然后由容器提供。 這樣做的好處是，類A不依賴于類B的實現，這樣在一定程度上解決了耦合問題。 在Laravel的服務容器中，為了實現控制反轉，可以有以下兩種： 依賴注入（Dependency Injection）。 綁定。