最近读Flask的文档，读到很多关于Context(上下文)的术语，如应用上下文，请求上下文等，查阅资料但没有得到理解？有没有比较好的解释？
context其实说白了，和文章的上下文是一个意思，在通俗一点，我觉得叫环境更好。
....
林冲大叫一声“啊也！”
....
问:这句话林冲的“啊也”表达了林冲怎样的心里？
答:啊你妈个头啊！
看，一篇文章，给你摘录一段，没前没后，你读不懂，因为有语境，就是语言环境存在，一段话说了什么，要通过上下文(文章的上下文)来推断。
子程序之于程序，进程之于操作系统，甚至app的一屏之于app，都是一个道理。
程序执行了部分到达子程序，子程序要获得结果，要用到程序之前的一些结果(包括但不限于外部变量值，外部对象等等)；
app点击一个按钮进入一个新的界面，也要保存你是在哪个屏幕跳过来的等等信息，以便你点击返回的时候能正确跳回，如果不存肯定就无法正确跳回了。
看这些都是上下文的典型例子，理解成环境就可以，(而且上下文虽然叫上下文，但是程序里面一般都只有上文而已，只是叫的好听叫上下文。。进程中断在操作系统中是有上有下的，不过不给题主说了，免得产生新的问题)和其他传入对象参数没什么区别。
但是通常使用Context来描述有几个特点：
另外 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你就可以知道在交互之前你的模块是一个什么样的状态，然后你可以按照这个状态做相应的处理。
回复内容：
每一段程序都有很多外部变量。只有像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你就可以知道在交互之前你的模块是一个什么样的状态，然后你可以按照这个状态做相应的处理。