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

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 很差。在上下文中携带任意值的可能性实际上是这种类型的一个缺陷，其设计者对此感到遗憾，因为它创建了一种反模式（处理上下文作为某种状态的正确方法是明确地拥有一组值）传遍了）。上下文存在的主要原因是它们提供了信号的树状传播（在上下文的情况下是取消或“完成”）。所以上下文背后的原始想法如下：“根”上下文对象是为传入请求创建的。需要代表请求执行的每个“任务”都与其自己的上下文相关联，该上下文源自请求的上下文。这些任务可能会产生其他任务等等。正如您所看到的，形成了“工作单元”的层次结构，链接到对象，这是这些单元存在和执行的原因。当传入请求被取消时（例如，客户端的套接字断开连接），与其关联的上下文对象也会被取消，然后所有链接的任务都会收到它，因为它从生成的上下文树的根向下传播到其离开——确保为请求执行的所有任务（最终）被取消。当然，为了使其发挥作用，每个“任务”（通常是一个执行某些操作的 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)}