到底“上下文”该如何去理解？
比如说：“XXX指定上下文对象”，“上下文修改路径”，“PHP 提供了多种上下文选项和参数”
有种想吐血的感觉~！
上下文指的是状态。图灵机需要保持一个具体状态才能执行下一步计算，计算完了对状态进行修改。这个抽象的状态就是上下文（对当前执行的操作来说）
上下文 = context。
例如“PHP 提供了多种上下文选项和参数”，就是php手册的原文：PHP offers various context options and parameters。
这种翻译往往是生硬翻译，译者自己都不懂原文意思的产物。
上下文即Context。Context即上下文.
其实你把它理解为 当前程序的运行环境 就好了.
遇到这种词汇，要搞清楚原文是什么，然后去理解原文中试图表达的意思，有时候必须得绕过中文。
例如你说的上下文（Context），我不知道如何去精确描述，我的理解也就是直译的语境，形容的就是当前描述的代码片段所处的环境，如果你有过断点调试的经验，你可以理解成断点处所有的变量、对象、程序执行结果的总和，就是此时此刻的上下文。
类似的东西还有Javascript中的Attribute和Proterty等等，我曾把他们翻译为属性和特性，但是跟国内一些维护前端开源项目的人（就是熟知的那几个）沟通学习后，我发现他们还是习惯直接记忆英文，跳过大脑中“替换为中文”的步骤。
其实我觉得这个问题挺有意思的，它反映出了我一直以来秉承的一个观点：
对于学习和使用编程语言来说，在某种程度／情形上，语文甚至比数学更重要！
编程语言之所以不叫编程“公式”而叫“语言”，恰恰是因为排除数学的部分（算法等）之后，表达就是它的一切。语句、表达式、控制结构、作用域、语境（即上下文，我个人偏好叫它语境）……这些东西哪个不是和表达紧密相连？我所说的语文，并不是狭义的课本，而是泛指使用自然语言时培养和锻炼出来的“理解能力”和“表达能力”。太多的程序员无法在编程语言的领域里更进一步突破自己的瓶颈，根源不在什么算法、逻辑上，而是在于“弱得可怜”的表达能力和理解能力（无恶意，只是相对于同期的逻辑思维能力而言）。
拿这个“上下文”来说吧，我们都知道程序执行是有过程的，这个过程会在许许多多个执行环境中切换，最终到达终点。
如果你不关心内部的细节，那么你可以把一个独立的程序看做是一个完整的上下文，有东西进来，有东西出去（输入／输出），也就是所谓的“黑盒”。
然而我们是程序员，我们不可能不关心程序的内部细节。于是当你进入黑盒探索的时候，你就会遇到一个个保持独立，但又可能相互关联的语境。此时，清楚的分辨上下文的边界以及在每个上下文中分清对象是谁就变成了非常非常重要的能力！
如同楼上某位所言，我们天天都在处理“上下文”，身为以汉语为母语的我们来说，如果搞不清“上下文”是怎么一回事，我觉得你小时候语文一定很为难吧？
让我举个虚构的例子：
某时某地，你站在那儿没动（断点），听见俩人对话：“哎～你老实说，你到底喜不喜欢他？”，“哎呀……我真的不喜欢他！”
现在我们问你：对话中的“他”是谁？（想想看面向对象里的 this 或 self）
你肯定会说：“没上没下的，我哪儿知道是谁？！”你答对了！这就是“缺少上下文”的典型范例啊～
我们打断点在某一句，然后看到 debugger 告诉我们 this 的值是多少，于是我们就知道代码运行到这里是对还是错。但是 debugger 如何知道此时此刻 this 指的是谁呢？不妨自己想想试试，想明白了，就搞懂上下文了。
最后按照我的理解给一个总结：
所谓上下文，就是在某一个特定的时间点下（比如断点触发的那一刻），在某一个特定的位置（断点的那一行），你想要了解当前目标时所需要的前因后果。