1，直觀映像
flask確實是輕量級的web框架。wsgi方面主要依賴於werkzeug，html模板方面主要依賴於jinja2。


2，運作機制
主要機制：路由規則管理、請求管理、響應管理、藍本管理、上下文管理、會話管理、html模板管理
輔助機制：版本相容管理、擴充套件匯入管理、配置檔案管理、debug模式管理、訊號機制管理、測試管理


3，路由規則管理
將url按照已有的定義，註冊路由規則到app的屬性url_map中，並將檢視函式註冊到app的屬性view_functions中。
結合請求來講，獲取請求的url後，按照url_map中的資訊，找到url規則（否則報錯not found），提取檢視函式字串到view_functions中查詢對應的檢視函式例項，然後就可以進行請求的處理了。


4，請求管理
當請求到達之後，處理之前，需要預先檢查是否是第一個請求，如果是，則先執行已註冊到app.before_first_request_funcs中的函式，然後執行已註冊到app.url_value_preprocessors中的函式，然後執行已註冊到app.before_request_funcs中的函式。
然後進行對應檢視函式的執行，並返回一個物件


5，響應管理
當檢視函式返回物件後，程式會用該物件建立一個標準的響應物件，然後用app.after_request_funcs中的函式對該響應物件進行處理，最後返回該響應到發出請求的客戶端。


6，藍本管理
藍本定義也是一個類，並且該類的基類和Flask的基類一樣，說明了藍本其實和Flask是一個類似的東西。
再看其定義的程式碼，幾乎全是定義的裝飾器，並且裝飾器的執行幾乎全是呼叫app的方法。從應用上來講，藍本就是用來進行app應用的拆分管理的機制。另外提一句，舊版本曾經使用module名稱來進行同樣的拆分管理，現在已經全面被藍本替代了。


7，上下文管理
具體使用方法，官方文件寫的很全面，這裡介紹一些細節。
用到上下文的地方主要是當前缺乏應用上下文或者請求上下文時，這是就需要主動建立一個臨時的上下文環境。
使用with關鍵字和對上下文類定義魔法方法：__enter__和__exit__來管理上下文的建立和銷燬。
值得提出的是，flask使用棧來管理上下文，也就是說，當到達該上下文環境是，生效的永遠是當前程式碼的環境，當退出當前上下文環境後，上下文會被pop掉，那麼最新的上下文環境就是之前的那個還未pop掉的上下文環境。


8，會話管理
提供常用的session管理功能，其實是包含cookie機制。


9，html模板管理
提供了多種方法，包含裝飾器，字典等方式來讓使用者將自定義變數傳入模板環境，包括函式。其實最終呼叫的都是app.jinja_env.globals來新增變數字典


10，訊號機制管理
flask提供了訊號機制，併發送了一些重要的訊號，包含：
template_rendered：當進行模板渲染時
request_started ：當開始請求處理時
request_finished ：當請求處理完畢時
request_tearing_down：當請求銷燬時
got_request_exception ：當抓取到請求異常時
appcontext_tearing_down ：當進行應用上下文銷燬時
appcontext_pushed ：當應用上下文入棧時
appcontext_popped ：當應用上下文出棧時
message_flashed ：當flash訊息被成功推送時
訊息機制主要包含三部分，
1，建立，flask建立瞭如上的這些訊號
2，註冊，定義函式，並將其註冊到對應的訊號物件上
3，傳送，一旦有訊息傳送，那麼訊號就會呼叫對應的函式執行
目前訊息機制被部分flask擴充套件程式應用。