最近讀Flask的文檔，讀到很多關於Context(上下文)的術語，如應用上下文，請求上下文等，查閱資料但沒有得到理解？有沒有比較好的解釋？
回複內容：
每一段程式都有很多外部變數。只有像Add這種簡單的函數才是沒有外部變數的。一旦你的一段程式有了外部變數，這段程式就不完整，不能獨立運行。你為了使他們運行，就要給所有的外部變數一個一個寫一些值進去。這些值的集合就叫上下文。
譬如說在C++的lambda表達是裡面，[寫在這裡的就是上下文](int a, int b){ ... }。
context是environment的snapshot.你查不到是因為上下文這個東西不是一個具體的東西，上下文在不同的地方表示不同的含義，要感性理解。
context其實說白了，和文章的上下文是一個意思，在通俗一點，我覺得叫環境更好。
....
林沖大叫一聲“啊也！”
....
問:這句話林沖的“啊也”表達了林沖怎樣的心裡？
答:啊你媽個頭啊！
看，一篇文章，給你摘錄一段，沒前沒後，你讀不懂，因為有語境，就是語言環境存在，一段話說了什麼，要通過上下文(文章的上下文)來推斷。
子程式之於程式，進程之於作業系統，甚至app的一屏之於app，都是一個道理。
程式執行了部分到達子程式，子程式要獲得結果，要用到程式之前的一些結果(包括但不限於外部變數值，外部對象等等)；
app點擊一個按鈕進入一個新的介面，也要儲存你是在哪個螢幕跳過來的等等資訊，以便你點擊返回的時候能正確跳回，如果不存肯定就無法正確跳回了。
看這些都是內容相關的典型例子，理解成環境就可以，(而且上下文雖然叫上下文，但是程式裡面一般都只有上文而已，只是叫的好聽叫上下文。。進程中斷在作業系統中是有上有下的，不過不給題主說了，免得產生新的問題)和其他傳入對象參數沒什麼區別。
但是通常使用Context來描述有幾個特點：
- 被傳入Context的部分（組件），內部需要頻繁的擷取Context的data和調用function。對context有很強的依賴，實現建立在context的基礎上。
- Context會被較為多數部分（組件）所需要，在軟體實現部分Context會在某個scene下出現單一執行個體化，然後被多個部分（組件）執行個體對象調用。出現局部全域化。
- Context會持有很多狀態data。
- Coder習慣，命名選擇困難下的膠合產物。
另外 Context的中文翻譯是誰想出來的，站出來我保證不打你。其他語言不知道。
在 Scheme 中完整的表述應該是 e 在 E 中的上下文，其中 E 是一個運算式，e是該運算式的子運算式。
如 (+ 1 2 3) 中有子運算式 2 ，那麼 2 在 (+ 1 2 3) 中就有一個上下文。
在 Scheme 中上下文是一個過程（即函數)。
構造這個函數很簡單，第一步把子運算式挖掉，用空洞(hole) 佔住位置。
(+ 1 ~ 3)，~ 表示空洞。
第二步，將上一步的結果用 lambda 包裹起來，得到函數。
(lambda (~) (+ 1 ~ 3))。即為 2 在 (+ 1 2 3) 中的上下文。
同理 (+ 2 3) 在 (/ (+ 2 3) 4) 中的上下文即是函數 (lambda (~) (/ ~ 4))。
上下文有一個性質，用原來的子運算式調用上下文時得到原來的運算式。
((lambda (~) (+ 1 ~ 3)) 2) ;;=> (+ 1 2 3)
((lambda (~) (/ ~ 4)) (+ 2 3)) ;; => (/ (+ 2 3) 4)
因為上下文有這個性質，可以很方便的用上下文來解釋 不動點(y 組合子) 和 延續等概念。在語言學裡，語意學（semantics）不包含語境（context），語用學（pragmatics）則考慮到語境對語意的影響。
在編程中，也就是一些編程構件（如函數）需要考慮到當時的編譯／運行環境，才能理解它的語意／運行結果。理解了stateless的概念就不會有疑惑了。基於會話，每個處理模組的通訊需要一個會話識別標識和內容容器內交換，那個就是上下文。一般來說是想要有個object來儲存狀態，想不出好的名字然後就叫context了簡單的說就是一個狀態，當與其它模組進行互動，其它模組執行完了通知你的時候，通過context你就可以知道在互動之前你的模組是一個什麼樣的狀態，然後你可以按照這個狀態做相應的處理。
