在Flask中處理請求時，應用會生成一個“請求上下文”物件。整個請求的處理過程，都會在這個上下文物件中進行。這保證了請求的處理過程不被干擾。處理請求的具體程式碼如下：
|
1 2 3 4 5 |
def wsgi_app(self, environ, start_response): with self.request_context(environ): # with語句中生成一個`response`物件 ... return response(environ, start_response) |
在Flask 0.9版本之前，應用只有“請求上下文”物件，它包含了和請求處理相關的資訊。同時Flask還根據werkzeug.local模組中實現的一種資料結構LocalStack用來儲存“請求上下文”物件。這在{% post_link 一個Flask應用執行過程剖析 一個Flask應用執行過程剖析 %}中有所介紹。在0.9版本中，Flask又引入了“應用上下文”的概念。本文主要Flask中的這兩個“上下文”物件。
LocalStack
在介紹“請求上下文”和“應用上下文”之前，我們對LocalStack簡要做一個回顧。在Werkzeug庫——local模組一文中，我們講解了werkzeug.local模組中實現的三個類Local、LocalStack和LocalProxy。關於它們的概念和詳細介紹，可以檢視上面的文章。這裡，我們用一個例子來說明Flask中使用的一種資料結構LocalStack。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
>>> from werkzeug.local import LocalStack >>> import threading # 建立一個`LocalStack`物件 >>> local_stack = LocalStack() # 檢視local_stack中儲存的資訊 >>> local_stack._local.__storage__ {} # 定義一個函式，這個函式可以向`LocalStack`中新增資料 >>> def worker(i): local_stack.push(i) # 使用3個執行緒執行函式`worker` >>> for i in range(3): t = threading.Thread(target=worker, args=(i,)) t.start() # 再次檢視local_stack中儲存的資訊 >>> local_stack._local.__storage__ {<greenlet.greenlet at 0x4bee5a0>: {'stack': [2]}, <greenlet.greenlet at 0x4bee638>: {'stack': [1]}, <greenlet.greenlet at 0x4bee6d0>: {'stack': [0]} } |
由上面的例子可以看出，儲存在LocalStack中的資訊以字典的形式存在：鍵為執行緒/協程的標識數值，值也是字典形式。每當有一個執行緒/協程上要將一個物件push進LocalStack棧中，會形成如上一個“鍵-值”對。這樣的一種結構很好地實現了執行緒/協程的隔離，每個執行緒/協程都會根據自己執行緒/協程的標識數值確定儲存在棧結構中的值。
LocalStack還實現了push、pop、top等方法。其中top方法永遠指向棧頂的元素。棧頂的元素是指當前執行緒/協程中最後被推入棧中的元素，即local_stack._local.stack[-1](注意，是stack鍵對應的物件中最後被推入的元素)。
請求上下文
Flask中所有的請求處理都在“請求上下文”中進行，在它設計之初便就有這個概念。由於0.9版本程式碼比較複雜，這裡還是以0.1版本的程式碼為例進行說明。本質上這兩個版本的“請求上下文”的執行原理沒有變化，只是新版本增加了一些功能，這點在後面再進行解釋。
請求上下文——0.1版本
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
# 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() |
由上面“請求上下文”的實現可知：
- “請求上下文”是一個上下文物件，實現了
__enter__和__exit__方法。可以使用with語句構造一個上下文環境。 - 進入上下文環境時，
_request_ctx_stack這個棧中會推入一個_RequestContext物件。這個棧結構就是上面講的LocalStack棧。 - 推入棧中的
_RequestContext物件有一些屬性，包含了請求的的所有相關資訊。例如app、request、session、g、flashes。還有一個url_adapter，這個物件可以進行URL匹配。 - 在
with語句構造的上下文環境中可以進行請求處理。當退出上下文環境時，_request_ctx_stack這個棧會銷燬剛才儲存的上下文物件。
以上的執行邏輯使得請求的處理始終在一個上下文環境中，這保證了請求處理過程不被干擾，而且請求上下文物件儲存在LocalStack棧中，也很好地實現了執行緒/協程的隔離。
以下是一個簡單的例子：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
# example - Flask v0.1 >>> from flask import Flask, _request_ctx_stack >>> import threading >>> app = Flask(__name__) # 先觀察_request_ctx_stack中包含的資訊 >>> _request_ctx_stack._local.__storage__ {} # 建立一個函式，用於向棧中推入請求上下文 # 本例中不使用`with`語句 >>> def worker(): # 使用應用的test_request_context()方法建立請求上下文 request_context = app.test_request_context() _request_ctx_stack.push(request_context) # 建立3個程式分別執行worker方法 >>> for i in range(3): t = threading.Thread(target=worker) t.start() # 再觀察_request_ctx_stack中包含的資訊 >>> _request_ctx_stack._local.__storage__ {<greenlet.greenlet at 0x5e45df0>: {'stack': [<flask._RequestContext at 0x710c668>]}, <greenlet.greenlet at 0x5e45e88>: {'stack': [<flask._RequestContext at 0x7107f28>]}, <greenlet.greenlet at 0x5e45f20>: {'stack': [<flask._RequestContext at 0x71077f0>]} } |
上面的結果顯示：_request_ctx_stack中為每一個執行緒建立了一個“鍵-值”對，每一“鍵-值”對中包含一個請求上下文物件。如果使用with語句，在離開上下文環境時棧中銷燬儲存的上下文物件資訊。
請求上下文——0.9版本
在0.9版本中，Flask引入了“應用上下文”的概念，這對“請求上下文”的實現有一定的改變。這個版本的“請求上下文”也是一個上下文物件。在使用with語句進入上下文環境後，_request_ctx_stack會儲存這個上下文物件。不過與0.1版本相比，有以下幾點改變：
- 請求上下文實現了
push、pop方法，這使得對於請求上下文的操作更加的靈活； - 伴隨著請求上下文物件的生成並儲存在棧結構中，Flask還會生成一個“應用上下文”物件，而且“應用上下文”物件也會儲存在另一個棧結構中去。這是兩個版本最大的不同。
我們先看一下0.9版本相關的程式碼：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
# Flask v0.9 def push(self): """Binds the request context to the current context.""" top = _request_ctx_stack.top if top is not None and top.preserved: top.pop() # Before we push the request context we have to ensure that there # is an application context. app_ctx = _app_ctx_stack.top if app_ctx is None or app_ctx.app != self.app: app_ctx = self.app.app_context() app_ctx.push() self._implicit_app_ctx_stack.append(app_ctx) else: self._implicit_app_ctx_stack.append(None) _request_ctx_stack.push(self) self.session = self.app.open_session(self.request) if self.session is None: self.session = self.app.make_null_session() |
我們注意到，0.9版本的“請求上下文”的pop方法中，當要將一個“請求上下文”推入_request_ctx_stack棧中的時候，會先檢查另一個棧_app_ctx_stack的棧頂是否存在“應用上下文”物件或者棧頂的“應用上下文”物件的應用是否是當前應用。如果不存在或者不是當前物件，Flask會自動先生成一個“應用上下文”物件，並將其推入_app_ctx_stack中。
我們再看離開上下文時的相關程式碼：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
# Flask v0.9 def pop(self, exc=None): """Pops the request context and unbinds it by doing that. This will also trigger the execution of functions registered by the :meth:`~flask.Flask.teardown_request` decorator. .. versionchanged:: 0.9 Added the `exc` argument. """ app_ctx = self._implicit_app_ctx_stack.pop() clear_request = False if not self._implicit_app_ctx_stack: self.preserved = False if exc is None: exc = sys.exc_info()[1] self.app.do_teardown_request(exc) clear_request = True rv = _request_ctx_stack.pop() assert rv is self, 'Popped wrong request context. (%r instead of %r)' % (rv, self) # get rid of circular dependencies at the end of the request # so that we don't require the GC to be active. if clear_request: rv.request.environ['werkzeug.request'] = None # Get rid of the app as well if necessary. if app_ctx is not None: app_ctx.pop(exc) |
上面程式碼中的細節先不討論。注意到當要離開以上“請求上下文”環境的時候，Flask會先將“請求上下文”物件從_request_ctx_stack棧中銷燬，之後會根據實際的情況確定銷燬“應用上下文”物件。
以下還是以一個簡單的例子進行說明：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
# example - Flask v0.9 >>> from flask import Flask, _request_ctx_stack, _app_ctx_stack >>> app = Flask(__name__) # 先檢查兩個棧的內容 >>> _request_ctx_stack._local.__storage__ {} >>> _app_ctx_stack._local.__storage__ {} # 生成一個請求上下文物件 >>> request_context = app.test_request_context() >>> request_context.push() # 請求上下文推入棧後，再次檢視兩個棧的內容 >>> _request_ctx_stack._local.__storage__ {<greenlet.greenlet at 0x6eb32a8>: {'stack': [<RequestContext 'http://localhost/' [GET] of __main__>]}} >>> _app_ctx_stack._local.__storage__ {<greenlet.greenlet at 0x6eb32a8>: {'stack': [<flask.ctx.AppContext at 0x5c96a58>]}} >>> request_context.pop() # 銷燬請求上下文時，再次檢視兩個棧的內容 >>> _request_ctx_stack._local.__storage__ {} >>> _app_ctx_stack._local.__storage__ {} |
應用上下文
上部分中簡單介紹了“應用上下文”和“請求上下文”的關係。那什麼是“應用上下文”呢？我們先看一下它的類：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
class AppContext(object): """The application context binds an application object implicitly to the current thread or greenlet, similar to how the :class:`RequestContext` binds request information. The application context is also implicitly created if a request context is created but the application is not on top of the individual application context. """ def __init__(self, app): self.app = app self.url_adapter = app.create_url_adapter(None) # Like request context, app contexts can be pushed multiple times # but there a basic "refcount" is enough to track them. self._refcnt = 0 def push(self): """Binds the app context to the current context.""" self._refcnt += 1 _app_ctx_stack.push(self) def pop(self, exc=None): """Pops the app context.""" self._refcnt -= 1 if self._refcnt <= 0: if exc is None: exc = sys.exc_info()[1] self.app.do_teardown_appcontext(exc) rv = _app_ctx_stack.pop() assert rv is self, 'Popped wrong app context. (%r instead of %r)' \ % (rv, self) def __enter__(self): |
由以上程式碼可以看出：“應用上下文”也是一個上下文物件，可以使用with語句構造一個上下文環境，它也實現了push、pop等方法。“應用上下文”的建構函式也和“請求上下文”類似，都有app、url_adapter等屬性。“應用上下文”存在的一個主要功能就是確定請求所在的應用。
然而，以上的論述卻又讓人產生這樣的疑問：既然“請求上下文”中也包含app等和當前應用相關的資訊，那麼只要呼叫_request_ctx_stack.top.app或者魔法current_app就可以確定請求所在的應用了，那為什麼還需要“應用上下文”物件呢？對於單應用單請求來說，使用“請求上下文”確實就可以了。然而，Flask的設計理念之一就是多應用的支援。當在一個應用的請求上下文環境中，需要巢狀處理另一個應用的相關操作時，“請求上下文”顯然就不能很好地解決問題了。如何讓請求找到“正確”的應用呢？我們可能會想到，可以再增加一個請求上下文環境，並將其推入_request_ctx_stack棧中。由於兩個上下文環境的執行是獨立的，不會相互干擾，所以通過呼叫_request_ctx_stack.top.app或者魔法current_app也可以獲得當前上下文環境正在處理哪個應用。這種辦法在一定程度上可行，但是如果對於第二個應用的處理不涉及到相關請求，那也就無從談起“請求上下文”。
為了應對這個問題，Flask中將應用相關的資訊單獨拿出來，形成一個“應用上下文”物件。這個物件可以和“請求上下文”一起使用，也可以單獨拿出來使用。不過有一點需要注意的是：在建立“請求上下文”時一定要建立一個“應用上下文”物件。有了“應用上下文”物件，便可以很容易地確定當前處理哪個應用，這就是魔法current_app。在0.1版本中，current_app是對_request_ctx_stack.top.app的引用，而在0.9版本中current_app是對_app_ctx_stack.top.app的引用。
下面以一個多應用的例子進行說明：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
# example - Flask v0.9 >>> from flask import Flask, _request_ctx_stack, _app_ctx_stack # 建立兩個Flask應用 >>> app = Flask(__name__) >>> app2 = Flask(__name__) # 先檢視兩個棧中的內容 >>> _request_ctx_stack._local.__storage__ {} >>> _app_ctx_stack._local.__storage__ {} # 構建一個app的請求上下文環境，在這個環境中執行app2的相關操作 >>> with app.test_request_context(): print "Enter app's Request Context:" print _request_ctx_stack._local.__storage__ print _app_ctx_stack._local.__storage__ print with app2.app_context(): print "Enter app2's App Context:" print _request_ctx_stack._local.__storage__ print _app_ctx_stack._local.__storage__ print # do something print "Exit app2's App Context:" print _request_ctx_stack._local.__storage__ print _app_ctx_stack._local.__storage__ print # Result Enter app's Request Context: {<greenlet.greenlet object at 0x000000000727A178>: {'stack': [<RequestContext 'http://localhost/' [GET] of __main__>]}} {<greenlet.greenlet object at 0x000000000727A178>: {'stack': [<flask.ctx.AppContext object at 0x0000000005DD0DD8>]}} Enter app2's App Context: {<greenlet.greenlet object at 0x000000000727A178>: {'stack': [<RequestContext 'http://localhost/' [GET] of __main__>]}} {<greenlet.greenlet object at 0x000000000727A178>: {'stack': [<flask.ctx.AppContext object at 0x0000000005DD0DD8>, <flask.ctx.AppContext object at 0x0000000007313198>]}} Exit app2's App Context {<greenlet.greenlet object at 0x000000000727A178>: {'stack': [<RequestContext 'http://localhost/' [GET] of __main__>]}} {<greenlet.greenlet object at 0x000000000727A178>: {'stack': [<flask.ctx.AppContext object at 0x0000000005DD0DD8>]}} |
在以上的例子中：
- 我們首先建立了兩個Flask應用
app和app2； - 接著我們構建了一個
app的請求上下文環境。當進入這個環境中時，這時檢視兩個棧的內容，發現兩個棧中已經有了當前請求的請求上下文物件和應用上下文物件。並且棧頂的元素都是app的請求上下文和應用上下文； - 之後，我們再在這個環境中巢狀
app2的應用上下文。當進入app2的應用上下文環境時，兩個上下文環境便隔離開來，此時再檢視兩個棧的內容，發現_app_ctx_stack中推入了app2的應用上下文物件，並且棧頂指向它。這時在app2的應用上下文環境中，current_app便會一直指向app2； - 當離開
app2的應用上下文環境，_app_ctx_stack棧便會銷燬app2的應用上下文物件。這時檢視兩個棧的內容，發現兩個棧中只有app的請求的請求上下文物件和應用上下文物件。 - 最後，離開
app的請求上下文環境後，兩個棧便會銷燬app的請求的請求上下文物件和應用上下文物件，棧為空。
與上下文物件有關的“全域性變數”
在Flask中，為了更加方便地處理一些變數，特地提出了“全域性變數”的概念。這些全域性變數有：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
# Flask v0.9 _request_ctx_stack = LocalStack() _app_ctx_stack = LocalStack() current_app = LocalProxy(_find_app) request = LocalProxy(partial(_lookup_object, 'request')) session = LocalProxy(partial(_lookup_object, 'session')) g = LocalProxy(partial(_lookup_object, 'g')) # 輔助函式 def _lookup_object(name): top = _request_ctx_stack.top if top is None: raise RuntimeError('working outside of request context') return getattr(top, name) def _find_app(): top = _app_ctx_stack.top if top is None: raise RuntimeError('working outside of application context') return top.app |
可以看出，Flask中使用的一些“全域性變數”，包括current_app、request、session、g等都來自於上下文物件。其中current_app一直指向_app_ctx_stack棧頂的“應用上下文”物件，是對當前應用的引用。而request、session、g等一直指向_request_ctx_stack棧頂的“請求上下文”物件，分別引用請求上下文的request、session和g。不過，從 Flask 0.10 起，物件 g 儲存在應用上下文中而不再是請求上下文中。
另外一個問題，在形成這些“全域性變數”的時候，使用了werkzeug.local模組的LocalProxy類。之所以要用該類，主要是為了動態地實現對棧頂元素的引用。如果不使用這個類，在生成上述“全域性變數”的時候，它們因為指向棧頂元素，而棧頂元素此時為None，所以這些變數也會被設定為None常量。後續即使有上下文物件被推入棧中，相應的“全域性變數”也不會發生改變。為了動態地實現對棧頂元素的引用，這裡必須使用werkzeug.local模組的LocalProxy類。