我应该在每个传入请求中创建新的上下文吗？

Question

在过去的几天里，我一直在阅读有关 Go 的内容，并且我不断回顾的一个概念是上下文。我想我理解创建这样一个结构背后的动机。我不明白的是在传入 HTTP 请求中使用上下文时的特定用例。假设我们有一个追随者httpHandlerFunc。在该处理程序内部，我们调用一个需要传递上下文的函数。我经常看到这个解决方案func myHandler(w http.ResponseWriter, r *http.Request) {  ctx := context.WithValue(context.Background(), "request", r)  otherFunc(ctx)}我的问题是，为什么我们不直接从请求中传递上下文，就像这样func myHandler(w http.ResponseWriter, r *http.Request) {  otherFunc(r.Context())}既然我们希望上下文流过我们的程序，那么传递请求的上下文不是更有意义吗？我认为创建后台上下文是我们只想在根父级中执行的操作，就像init()函数一样。

Answer 1

您可能会错过上下文的要点 - 据说是由于您正在处理的 HOWTO 很差。

在上下文中携带任意值的可能性实际上是这种类型的一个缺陷，其设计者对此感到遗憾，因为它创建了一种反模式（处理上下文作为某种状态的正确方法是明确地拥有一组值）传遍了）。

上下文存在的主要原因是它们提供了信号的树状传播（在上下文的情况下是取消或“完成”）。所以上下文背后的原始想法如下：

1. “根”上下文对象是为传入请求创建的。

2. 需要代表请求执行的每个“任务”都与其自己的上下文相关联，该上下文源自请求的上下文。

3. 这些任务可能会产生其他任务等等。

   正如您所看到的，形成了“工作单元”的层次结构，链接到对象，这是这些单元存在和执行的原因。

4. 当传入请求被取消时（例如，客户端的套接字断开连接），与其关联的上下文对象也会被取消，然后所有链接的任务都会收到它，因为它从生成的上下文树的根向下传播到其离开——确保为请求执行的所有任务（最终）被取消。

   当然，为了使其发挥作用，每个“任务”（通常是一个执行某些操作的 goroutine）都需要从传递给它的上下文中“监听”该“完成”信号。

上下文还支持开箱即用的超时，因此您可以创建一个上下文，该上下文在经过一些固定时间间隔后会自行取消。

那么，回到你问题中的例子。

第一个示例完全忽略请求的上下文，并从头开始创建上下文，表面上唯一的原因是在其中携带内容（不好）。

第二个示例可能将上下文用于其预期目的（但我们不知道，因为我们看不到otherFunc）。

---

1 实际上，如果要控制的任务没有其他策略“添加”到现有的父上下文，则不需要创建新的上下文。派生的想法是实现额外的方法来取消此特定任务中的工作，并尊重父上下文的取消。 例如，为特定任务派生的上下文可以有自己的截止日期，或者有办法仅取消该特定上下文。
当然，可以为任务导出复杂的嵌套上下文：例如，可以从父上下文导出具有截止日期的上下文，然后可以从前者导出可取消的上下文。结果将是一个上下文被代码明确地取消，或者当截止日期到期或当父上下文发出取消信号时被取消。

Answer 2

你的两个例子做了完全不同的事情。

func myHandler(w http.ResponseWriter, r *http.Request) {

  ctx := context.WithValue(context.Background(), "request", r)

  otherFunc(ctx)

}

这将创建一个新的上下文，并将请求存储为一个值。很少（如果有的话）有任何理由这样做。一个更惯用的解决方案是将请求传递给otherFunc像这样的：

func myHandler(w http.ResponseWriter, r *http.Request) {

  otherFunc(r)

}

如果您确实需要将请求作为上下文值传递，则可能应该使用当前请求的上下文来执行此操作，如下所示：

func myHandler(w http.ResponseWriter, r *http.Request) {

  ctx := context.WithValue(r.Context(), "request", r)

  otherFunc(ctx)

}