[TOC] # beego 的 MVC 架構介紹 beego 是一個典型的 MVC 框架，它的整個執行邏輯如下圖所示：  通過文字來描述如下： 1. 在監聽的端口接收數據，默認監聽在 8080 端口。 2. 用戶請求到達 8080 端口之后進入 beego 的處理邏輯。 3. 初始化 Context 對象，根據請求判斷是否為 WebSocket 請求，如果是的話設置 Input，同時判斷請求的方法是否在標準請求方法中（“get“”post“”put“”delete“”patch“”options“”head“），防止用戶的惡意偽造請求攻擊造成不必要的影響。 4. 執行 BeforeRouter 過濾器，當然在 beego 里面有開關設置。如果用戶設置了過濾器，那么該開關打開，這樣可以提高在沒有開啟過濾器的情況下提高執行效率。如果在執行過濾器過程中，responseWriter 已經有數據輸出了，那么就提前結束該請求，直接跳轉到監控判斷。 5. 開始執行靜態文件的處理，查看用戶的請求 URL 是否和注冊在靜態文件處理 StaticDir 中的 prefix 是否匹配。如果匹配的話，采用 `http` 包中默認的 ServeFile 來處理靜態文件。 6. 如果不是靜態文件開始初始化 session 模塊(如果開啟 session 的話)，這個里面大家需要注意，如果你的 BeforeRouter 過濾器用到了 session 就會報錯，你應該把加入到 AfterStatic 過濾器中。 7. 開始執行 AfterStatic 過濾器，如果在執行過濾器過程中，responseWriter 已經有數據輸出了，那么就提前結束該請求，直接跳轉到監控判斷。 8. 執行過過濾器之后，開始從固定的路由規則中查找和請求 URL 相匹配的對象。這個匹配是全匹配規則，即如果用戶請求的 URL 是 `/hello/world`，那么固定規則中 `/hello` 是不會匹配的，只有完全匹配才算匹配。如果匹配的話就進入邏輯執行，如果不匹配進入下一環節的正則匹配。 9. 正則匹配是進行正則的全匹配，這個正則是按照用戶添加 beego 路由順序來進行匹配的，也就是說，如果你在添加路由的時候你的順序影響你的匹配。和固定匹配一樣，如果匹配的話就進行邏輯執行，如果不匹配進入 Auto 匹配。 10. 如果用戶注冊了 AutoRouter，那么會通過 `controller/method` 這樣的方式去查找對應的 Controller 和他內置的方法，如果找到就開始執行邏輯，如果找不到就跳轉到監控判斷。 11. 如果找到 Controller 的話，那么就開始執行邏輯，首先執行 BeforeExec 過濾器，如果在執行過濾器過程中，responseWriter 已經有數據輸出了，那么就提前結束該請求，直接跳轉到監控判斷。 12. Controller 開始執行 Init 函數，初始化基本的一些信息，這個函數一般都是 beego.Controller 的初始化，不建議用戶繼承的時候修改該函數。 13. 是否開啟了 XSRF，開啟的話就調用 Controller 的 XsrfToken，然后如果是 POST 請求就調用 CheckXsrfCookie 方法。 14. 繼續執行 Controller 的 Prepare 函數，這個函數一般是預留給用戶的，用來做 Controller 里面的一些參數初始化之類的工作。如果在初始化中 responseWriter 有輸出，那么就直接進入 Finish 函數邏輯。 15. 如果沒有輸出的話，那么根據用戶注冊的方法執行相應的邏輯，如果用戶沒有注冊，那么就調用 http.Method 對應的方法（Get/Post 等）。執行相應的邏輯，例如數據讀取，數據賦值，模板顯示之類的，或者直接輸出 JSON 或者 XML。 16. 如果 responseWriter 沒有輸出，那么就調用 Render 函數進行模板輸出。 17. 執行 Controller 的 Finish 函數，這個函數是預留給用戶用來重寫的，用于釋放一些資源。釋放在 Init 中初始化的信息數據。 18. 執行 AfterExec 過濾器，如果有輸出的話就跳轉到監控判斷邏輯。 18. 執行 Controller 的 Destructor，用于釋放 Init 中初始化的一些數據。 19. 如果這一路執行下來都沒有找到路由，那么會調用 404 顯示找不到該頁面。 20. 最后所有的邏輯都匯聚到了監控判斷，如果用戶開啟了監控模塊（默認是開啟一個 8088 端口用于進程內監控），這樣就會把訪問的請求鏈接扔給監控程序去記錄當前訪問的 QPS，對應的鏈接訪問的執行時間，請求鏈接等。