假设您去看牙医拔了一颗牙齿。

当接待员询问您的姓名时，这是他们开始约会所需的信息。在此示例中，您的姓名是 _ 上下文信息 。因此，在看牙医的 _ 情况下
，您需要提供您的姓名才能拔牙。

现在假设你走到银行。

在银行，您要求提取 100 美元。出纳员需要在给您钱之前确定您的身份，因此您可能需要向他们出示驾驶执照或刷您的 ATM 卡并输入您的 PIN
码。无论哪种方式，您提供的是 context 。出纳员使用此信息推动交易向前发展。然后他们可能会询问您要退出哪个帐户。当您回答 “我的储蓄账户”
时，就 更能 说明问题了。

您提供的上下文越多，对方帮助处理您的请求的知识就越多。有时上下文是可选的（例如在您的 Google
搜索中输入越来越多的单词以获得更好的结果），有时它是必需的（例如在 ATM 上提供您的 PIN 码）。无论哪种方式，通常都是有助于完成工作的信息。

现在假设你带着 100 美元买了一张飞机票，在你的嘴愈合时飞往温暖的地方。

你到达了一个阳光明媚的目的地，但你的包没能成功。它在机场系统的某个地方丢失了。因此，您将您的“行李领取票”（上面有条形码的贴纸）带到“丢失行李处”。服务台后面的人首先要的是那张带有您的行李号的票。
这是一些必需的 context 的示例。

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

这是有趣的部分：对于许多软件和 API， 所需的上下文 通常最终作为方法签名中的实际参数，而 可选上下文
则位于其他地方，例如可以包含任何内容的灵活键值映射（并且可能为空） ) 或进入线程本地存储，如果需要可以访问它。

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

希望有帮助。