相信很多初學Flask的同學（包括我自己），在閱讀官方文件或者Flask的學習資料時，對於它的認識是從以下的一段程式碼開始的：

from flask import Flask app = Flask(__name__) @app.route('/') def index(): return "Hello World!" if __name__ == '__main__': app.run()

12345678910

from flask import Flaskapp=Flask(__name__)@app.route('/')def index():return"Hello World!"if__name__=='__main__':app.run()

執行如上程式碼，在瀏覽器中訪問http://localhost:5000/，便可以看到Hello World!出現了。這是一個很簡單的Flask的應用。

然而，這段程式碼怎麼執行起來的呢？一個Flask應用運轉的背後又有哪些邏輯呢？如果你只關心Web應用，那對這些問題不關注也可以，但從整個Web程式設計的角度來看，這些問題非常有意義。本文就主要針對一個Flask應用的執行過程進行簡要分析，後續文章還會對Flask框架的一些具體問題進行分析。

為了分析方便，本文采用 Flask 0.1版本 的原始碼進行相關問題的探索。

一些準備知識

在正式分析Flask之前，有一些準備知識需要先了解一下：

1. 使用Flask框架開發的屬於Web應用。由於Python使用WSGI閘道器，所以這個應用也可以叫WSGI應用；
2. 伺服器、Web應用的設計應該遵循閘道器介面的一些規範。對於WSGI閘道器，要求Web應用實現一個函式或者一個可呼叫物件webapp(environ, start_response)。伺服器或閘道器中要定義start_response函式並且呼叫Web應用。關於這部分的內容可以參考：wsgiref包——符合WSGI標準的Web服務實現（一）
   。
3. Flask依賴於底層庫werkzeug。相關內容可以參考：Werkzeug庫簡介。

本文暫時不對伺服器或閘道器的具體內容進行介紹，只需對伺服器、閘道器、Web應用之間有怎樣的關係，以及它們之間如何呼叫有一個瞭解即可。

一個Flask應用執行的過程

1. 例項化一個Flask應用

使用app = Flask(__name__)，可以例項化一個Flask應用。例項化的Flask應用有一些要點或特性需要注意一下：

1. 對於請求和響應的處理，Flask使用werkzeug庫中的Request類和Response類。對於這兩個類的相關內容可以參考：Werkzeug庫——wrappers模組。
2. 對於URL模式的處理，Flask應用使用werkzeug庫中的Map類和Rule類，每一個URL模式對應一個Rule例項，這些Rule例項最終會作為引數傳遞給Map類構造包含所有URL模式的一個“地圖”。這個地圖可以用來匹配請求中的URL資訊，關於Map類和Rule類的相關知識可以參考：Werkzeug庫——routing模組。
3. 當例項化一個Flask應用app（這個應用的名字可以隨便定義）之後，對於如何新增URL模式，Flask採取了一種更加優雅的模式，對於這點可以和Django的做法進行比較。Flask採取裝飾器的方法，將URL規則和檢視函式結合在一起寫，其中主要的函式是route。在上面例子中：
   @app.route('/') def index(): pass

   123	@app.route('/')def index():pass

   
   這樣寫檢視函式，會將'/'這條URL規則和檢視函式index()聯絡起來，並且會形成一個Rule例項，再新增進Map例項中去。當訪問'/'時，會執行index()。關於Flask匹配URL的內容，可以參考後續文章。
4. 例項化Flask應用時，會創造一個Jinja環境，這是Flask自帶的一種模板引擎。可以檢視Jinja文件，這裡先暫時不做相關介紹。
5. 例項化的Flask應用是一個可呼叫物件。在前面講到，Web應用要遵循WSGI規範，就要實現一個函式或者一個可呼叫物件webapp(environ, start_response)，以方便伺服器或閘道器呼叫。Flask應用通過__call__(environ, start_response)方法可以讓它被伺服器或閘道器呼叫。
   def __call__(self, environ, start_response): """Shortcut for :attr:`wsgi_app`""" return self.wsgi_app(environ, start_response)

   123	def __call__(self,environ,start_response):"""Shortcut for :attr:`wsgi_app`"""returnself.wsgi_app(environ,start_response)

   
   注意到呼叫該方法會執行wsgi_app(environ, start_response)方法，之所以這樣設計是為了在應用正式處理請求之前，可以載入一些“中介軟體”,以此改變Flask應用的相關特性。對於這一點後續會詳細分析。
6. Flask應用還有一些其他的屬性或方法，用於整個請求和響應過程。

2.呼叫Flask應用時會發生什麼

上面部分分析了例項化的Flask應用長什麼樣子。當一個完整的Flask應用例項化後，可以通過呼叫app.run()方法執行這個應用。

Flask應用的run()方法會呼叫werkzeug.serving模組中的run_simple方法。這個方法會建立一個本地的測試伺服器，並且在這個伺服器中執行Flask應用。關於伺服器的建立這裡不做說明，可以檢視werkzeug.serving模組的有關文件。

當伺服器開始呼叫Flask應用後，便會觸發Flask應用的__call__(environ, start_response)方法。其中environ由伺服器產生，start_response在伺服器中定義。

上面我們分析到當Flask應用被呼叫時會執行wsgi_app(environ, start_response)方法。可以看出，wsgi_app是真正被呼叫的WSGI應用，之所以這樣設計，就是為了在應用正式處理請求之前，wsgi_app可以被一些“中介軟體”裝飾，以便先行處理一些操作。為了便於理解，這裡先舉兩個例子進行說明。

例子一： 中介軟體SharedDataMiddleware

中介軟體SharedDataMiddleware是werkzeug.wsgi模組中的一個類。該類可以為Web應用提供靜態內容的支援。例如：

import os from werkzeug.wsgi import SharedDataMiddleware app = SharedDataMiddleware(app, { '/shared': os.path.join(os.path.dirname(__file__), 'shared') })

123456

import osfrom werkzeug.wsgi import SharedDataMiddlewareapp=SharedDataMiddleware(app,{'/shared':os.path.join(os.path.dirname(__file__),'shared')})

Flask應用通過以上的程式碼，app便會成為一個SharedDataMiddleware例項，之後便可以在http://example.com/shared/中訪問shared資料夾下的內容。

對於中介軟體SharedDataMiddleware，Flask應用在初始例項化的時候便有所應用。其中有這樣一段程式碼：

self.wsgi_app = SharedDataMiddleware(self.wsgi_app, { self.static_path: target })

123	self.wsgi_app=SharedDataMiddleware(self.wsgi_app,{self.static_path:target})

這段程式碼顯然會將wsgi_app變成一個SharedDataMiddleware物件，這個物件為Flask應用提供一個靜態資料夾/static。這樣，當整個Flask應用被呼叫時，self.wsgi_app(environ, start_response)會執行。由於此時self.wsgi_app是一個SharedDataMiddleware物件，所以會先觸發SharedDataMiddleware物件的__call__(environ, start_response)方法。如果此時的請示是要訪問/static這個資料夾，SharedDataMiddleware物件會直接返回響應；如果不是，則才會呼叫Flask應用的wsgi_app(environ.start_response)方法繼續處理請求。

例子二： 中介軟體DispatcherMiddleware

中介軟體DispatcherMiddleware也是werkzeug.wsgi模組中的一個類。這個類可以講不同的應用“合併”起來。以下是一個使用中介軟體DispatcherMiddleware的例子。

from flask import Flask from werkzeug import DispatcherMiddleware app1 = Flask(__name__) app2 = Flask(__name__) app = Flask(__name__) @app1.route('/') def index(): return "This is app1!" @app2.route('/') def index(): return "This is app2!" @app.route('/') def index(): return "This is app!" app = DispatcherMiddleware(app, { '/app1': app1, '/app2': app2 }) if __name__ == '__main__': from werkzeug.serving import run_simple run_simple('localhost', 5000, app)

123456789101112131415161718192021222324252627

from flask import Flaskfrom werkzeug import DispatcherMiddlewareapp1=Flask(__name__)app2=Flask(__name__)app=Flask(__name__)@app1.route('/')def index():return"This is app1!"@app2.route('/')def index():return"This is app2!"@app.route('/')def index():return"This is app!"app=DispatcherMiddleware(app,{'/app1':app1,'/app2':app2})if__name__=='__main__':from werkzeug.serving import run_simplerun_simple('localhost',5000,app)

在上面的例子中，我們首先建立了三個不同的Flask應用，併為每個應用建立了一個檢視函式。但是，我們使用了DispatcherMiddleware，將app1、app2和app合併起來。這樣，此時的app便成為一個DispatcherMiddleware物件。

當在伺服器中呼叫app時，由於它是一個DispatcherMiddleware物件，所以首先會觸發它的__call__(environ, start_response)方法。然後根據請求URL中的資訊來確定要呼叫哪個應用。例如：

• 如果訪問/，則會觸發app(environ, start_response)（注意： 此時app是一個Flask物件），進而處理要訪問app的請求；
• 如果訪問/app1，則會觸發app1(environ, start_response)，進而處理要訪問app1的請求。訪問/app2同理。

3. 和請求處理相關的上下文物件

當Flask應用真正處理請求時，wsgi_app(environ, start_response)被呼叫。這個函式是按照下面的方式執行的：

def wsgi_app(environ, start_response): with self.request_context(environ): ...

123	def wsgi_app(environ,start_response):with self.request_context(environ):...

請求上下文

可以看到，當Flask應用處理一個請求時，會構造一個上下文物件。所有的請求處理過程，都會在這個上下文物件中進行。這個上下文物件是_RequestContext類的例項。

# Flask v0.1 class _RequestContext(object): """The request context contains all request relevant information. It is created at the beginning of the request and pushed to the `_request_ctx_stack` and removed at the end of it. It will create the URL adapter and request object for the WSGI environment provided. """ def __init__(self, app, environ): self.app = app self.url_adapter = app.url_map.bind_to_environ(environ) self.request = app.request_class(environ) self.session = app.open_session(self.request) self.g = _RequestGlobals() self.flashes = None def __enter__(self): _request_ctx_stack.push(self) def __exit__(self, exc_type, exc_value, tb): # do not pop the request stack if we are in debug mode and an # exception happened. This will allow the debugger to still # access the request object in the interactive shell. if tb is None or not self.app.debug: _request_ctx_stack.pop()

12345678910111213141516171819202122232425

# Flask v0.1class_RequestContext(object):"""The request context contains all request relevant information.  It is    created at the beginning of the request and pushed to the    `_request_ctx_stack` and removed at the end of it.  It will create the    URL adapter and request object for the WSGI environment provided.    """def __init__(self,app,environ):self.app=appself.url_adapter=app.url_map.bind_to_environ(environ)self.request=app.request_class(environ)self.session=app.open_session(self.request)self.g=_RequestGlobals()self.flashes=Nonedef __enter__(self):_request_ctx_stack.push(self)def __exit__(self,exc_type,exc_value,tb):# do not pop the request stack if we are in debug mode and an# exception happened.  This will allow the debugger to still# access the request object in the interactive shell.iftb isNone ornotself.app.debug:_request_ctx_stack.pop()

根據_RequestContext上下文物件的定義，可以發現，在構造這個物件的時候添加了和Flask應用相關的一些屬性：

• app ——上下文物件的app屬性是當前的Flask應用；
• url_adapter ——上下文物件的url_adapter屬性是通過Flask應用中的Map例項構造成一個MapAdapter例項，主要功能是將請求中的URL和Map例項中的URL規則進行匹配；
• request ——上下文物件的request屬性是通過Request類構造的例項，反映請求的資訊；
• session ——上下文物件的session屬性儲存請求的會話資訊；
• g ——上下文物件的g屬性可以儲存全域性的一些變數。
• flashes ——訊息閃現的資訊。

LocalStack和一些“全域性變數”

注意： 當進入這個上下文物件時，會觸發_request_ctx_stack.push(self)。在這裡需要注意Flask中使用了werkzeug庫中定義的一種資料結構LocalStack。

_request_ctx_stack = LocalStack()

1	_request_ctx_stack=LocalStack()

關於LocalStack，可以參考：Werkzeug庫——local模組。LocalStack是一種棧結構，每當處理一個請求時，請求上下文物件_RequestContext會被放入這個棧結構中。資料在棧中儲存的形式表現成如下：

Python {880: {'stack': [<flask._RequestContext object>]}, 13232: {'stack': [<flask._RequestContext object>]}}

1	{880:{'stack':[<flask._RequestContext object>]},13232:{'stack':[<flask._RequestContext object>]}}

這是一個字典形式的結構，鍵代表當前執行緒/協程的標識數值，值代表當前執行緒/協程儲存的變數。werkzeug.local模組構造的這種結構，很容易實現執行緒/協程的分離。也正是這種特性，使得可以在Flask中訪問以下的“全域性變數”：

current_app = LocalProxy(lambda: _request_ctx_stack.top.app) request = LocalProxy(lambda: _request_ctx_stack.top.request) session = LocalProxy(lambda: _request_ctx_stack.top.session) g = LocalProxy(lambda: _request_ctx_stack.top.g)

1234	current_app=LocalProxy(lambda:_request_ctx_stack.top.app)request=LocalProxy(lambda:_request_ctx_stack.top.request)session=LocalProxy(lambda:_request_ctx_stack.top.session)g=LocalProxy(lambda:_request_ctx_stack.top.g)

其中_request_ctx_stack.top始終指向當前執行緒/協程中儲存的“請求上下文”，這樣像app、request、session、g等都可以以“全域性”的形式存在。這裡“全域性”是指在當前執行緒或協程當中。

由此可以看出，當處理請求時：

• 首先，會生成一個請求上下文物件，這個上下文物件包含請求相關的資訊。並且在進入上下文環境時，LocalStack會將這個上下文物件推入棧結構中以儲存這個物件；
• 在這個上下文環境中可以進行請求處理過程，這個稍後再介紹。不過可以以一種“全域性”的方式訪問上下文物件中的變數，例如app、request、session、g等；
• 當請求結束，退出上下文環境時，LocalStack會清理當前執行緒/協程產生的資料（請求上下文物件）；
• Flask 0.1版本只有“請求上下文”的概念，在Flask 0.9版本中又增加了“應用上下文”的概念。關於“應用上下文”，以後再加以分析。

4. 在上下文環境中處理請求

處理請求的過程定義在wsgi_app方法中，具體如下：

def wsgi_app(environ, start_response): with self.request_context(environ): rv = self.preprocess_request() if rv is None: rv = self.dispatch_request() response = self.make_response(rv) response = self.process_response(response) return response(environ, start_response)

12345678

def wsgi_app(environ,start_response):with self.request_context(environ):rv=self.preprocess_request()ifrv isNone:rv=self.dispatch_request()response=self.make_response(rv)response=self.process_response(response)returnresponse(environ,start_response)

從程式碼可以看出，在上下文物件中處理請求的過程分為以下幾個步驟：

1. 在請求正式被處理之前的一些操作，呼叫preprocess_request()方法，例如開啟一個數據庫連線等操作；
2. 正式處理請求。這個過程呼叫dispatch_request()方法，這個方法會根據URL匹配的情況呼叫相關的檢視函式；
3. 將從檢視函式返回的值轉變為一個Response物件；
4. 在響應被髮送到WSGI伺服器之前，呼叫process_response(response)做一些後續處理過程；
5. 呼叫response(environ, start_response)方法將響應傳送回WSGI伺服器。關於此方法的使用，可以參考：Werkzeug庫——wrappers模組；
6. 退出上下文環境時，LocalStack會清理當前執行緒/協程產生的資料（請求上下文物件）。