假设你去牙医那里拔了一颗牙。

当接待员问你的名字时，这是他们开始约会所需的信息。在这个例子中，你的名字是上下文信息。所以在看牙医的时候，你需要提供你的名字来拔牙。

现在假设你走到银行。

在银行，你要求取100美元。柜员在给你钱之前需要确认你的身份，所以你可能需要向他们出示驾照或刷你的ATM卡并输入你的密码。无论哪种方式，你所提供的都是上下文。出纳使用这些信息来推动交易。然后他们可能会问你想从哪个账户中提取。当你回答“我的储蓄账户”时，那就更有背景了。

你提供的背景信息越多，对方就有越多的知识来帮助处理你的请求。有时上下文是可选的(比如在谷歌搜索中输入越来越多的单词以获得更好的结果)，有时它是必须的(比如在自动取款机上提供你的密码)。不管怎样，这些信息通常都有助于完成工作。

现在让我们假设你拿着100美元买了一张机票，在你的口腔愈合期间飞往一个温暖的地方。

你到达了一个阳光明媚的目的地，但你的包没能到达。在机场系统的某个地方丢失了。所以，你拿着你的“行李认领票”(上面有条形码的贴纸)去行李丢失处。柜台后面的人首先要的是那张有你行李号的机票。这是一些必需上下文的例子。

但是行李员会问你更多关于你的包的信息，这样他们就可以更容易地找到你的包。他们问:“这是什么颜色?”它的尺寸是多少?它有轮子吗?它是硬的还是软的?虽然他们不一定需要这些信息，但如果你提供这些信息，就能帮助他们缩小范围。它减少了问题区域。它使搜索速度更快。这是可选的上下文。

有趣的是:对于很多软件和api来说，必需的上下文通常是方法签名中的实际参数，而可选的上下文则放在其他地方，比如一个灵活的键值映射，它可以包含任何内容(可能是空的)，或者放到线程本地存储中，在需要时可以访问它。

上面的例子来自现实生活，但你可以很容易地将它们映射到计算机科学领域。例如，HTTP报头包含上下文信息。每个报头都与正在发出的请求有关。或者当您发送全局事务ID作为两阶段提交流程的一部分时，该事务ID就是上下文。它帮助事务管理器协调工作，因为它是关于当前总体任务的信息。

我总是认为上下文是与我正在处理的对象或结构相关的特定状态。

For example, when you are using drawRect in a view (where all drawing must be done for a view) you must always get the currentGraphicsContext into which you will issue your core graphics statements. This context contains things like bounds of the view, the stroke colour, the stroke thickness for drawing a line, the fill color for filling a closed Path etc. this context (like most others) is just the current state at this point in time. so think of the graphics context in this case as just a set of state such as

描边厚度为1.5像素 填充颜色为黑色 视界为(155,200) 笔画颜色为红色

它基本上是当前时间点的状态……

假设你去牙医那里拔了一颗牙。

当接待员问你的名字时，这是他们开始约会所需的信息。在这个例子中，你的名字是上下文信息。所以在看牙医的时候，你需要提供你的名字来拔牙。

现在假设你走到银行。

在银行，你要求取100美元。柜员在给你钱之前需要确认你的身份，所以你可能需要向他们出示驾照或刷你的ATM卡并输入你的密码。无论哪种方式，你所提供的都是上下文。出纳使用这些信息来推动交易。然后他们可能会问你想从哪个账户中提取。当你回答“我的储蓄账户”时，那就更有背景了。

你提供的背景信息越多，对方就有越多的知识来帮助处理你的请求。有时上下文是可选的(比如在谷歌搜索中输入越来越多的单词以获得更好的结果)，有时它是必须的(比如在自动取款机上提供你的密码)。不管怎样，这些信息通常都有助于完成工作。

现在让我们假设你拿着100美元买了一张机票，在你的口腔愈合期间飞往一个温暖的地方。

你到达了一个阳光明媚的目的地，但你的包没能到达。在机场系统的某个地方丢失了。所以，你拿着你的“行李认领票”(上面有条形码的贴纸)去行李丢失处。柜台后面的人首先要的是那张有你行李号的机票。这是一些必需上下文的例子。

但是行李员会问你更多关于你的包的信息，这样他们就可以更容易地找到你的包。他们问:“这是什么颜色?”它的尺寸是多少?它有轮子吗?它是硬的还是软的?虽然他们不一定需要这些信息，但如果你提供这些信息，就能帮助他们缩小范围。它减少了问题区域。它使搜索速度更快。这是可选的上下文。

有趣的是:对于很多软件和api来说，必需的上下文通常是方法签名中的实际参数，而可选的上下文则放在其他地方，比如一个灵活的键值映射，它可以包含任何内容(可能是空的)，或者放到线程本地存储中，在需要时可以访问它。

上面的例子来自现实生活，但你可以很容易地将它们映射到计算机科学领域。例如，HTTP报头包含上下文信息。每个报头都与正在发出的请求有关。或者当您发送全局事务ID作为两阶段提交流程的一部分时，该事务ID就是上下文。它帮助事务管理器协调工作，因为它是关于当前总体任务的信息。

举一个实际的例子。假设你有一个特定的网页来获取/呈现基于用户(登录)和浏览器的语言的一些信息。获取信息的逻辑独立于用户和语言。您的页面将接收一个用户和一种语言…从逻辑上讲，是我还是你，是英语还是西班牙语并不重要。

一些伪代码:

class FooPage
{
    void handleRequest(RequestContext context)
    {
        User user = context.getUser();
        Locale locale = context.getLocale();

        … do some logic based on the context
    }
}

这并不难，但是理解这个概念需要一些时间

上下文可以看作是传递信息的桶。它通常用于传递不一定直接绑定到方法调用的东西，但仍然可能是相关的。外行描述它的方式可能是“你可能关心的东西”。

例如，如果你正在编写一个服务来更新db中的值，你可能会传入记录id和新值。

如果需要通用接口，还可以定义要传递的上下文，这样服务就可以执行任意业务逻辑。因此，您可以包括用户身份验证、用户会话状态等等……在上下文中，因为服务可能根据这些值执行额外的逻辑。

在您的案例中，上下文是运行应用程序的环境。

它提供了应用程序正常运行所需的信息/服务/功能。

HTH