Golang实用技巧
- Golang实用技巧
- Context
- 1. 为了gorouines更可靠，避免实用context.Background()
- 2. 不幸得是，context.Value 不是我们的朋友
- 3. 使用context.WithoutCancel 保持 context 活跃
- Context
Context
1. 为了gorouines更可靠，避免实用context.Background()
在我们同时管理多个任务时，我们会实用goroutine，对吧？每个goroutine专用于特定的功能，比如发HTTP请求或者查询数据库。当这些任务需要暂停时，问题就出现了，这也是棘手的地方。因为我们不希望goroutines永久停止或阻塞，没有办法退出。
“为什么我们应该避免直接使用 context.Background() ？”
我们之所以避免直接使用 context.Background()，主要是因为它无法在出现问题时停止或取消执行。它是我们能用context的最简单形式，没有值（values） 、没有截止日期（截止日期）、没有取消信号（cancellation signals）。当执行卡住或要顺利结束时，这可能会成为一个问题。
为了解决这个问题，通常我们依靠两个策略：取消（cancel）和超时（timeout）:
context.WithTimeout(ctx, duration)
context.WithTimeoutCause(ctx, duration, errors.New("custom message"))context.WithCancel(ctx)
context.WithCancelCause(ctx)context.WithDeadline(ctx)
context.WithDeadlineCause(ctx, deadline, errors.New("custom message"))
有了这些工具，我们启动每个 goroutine 都带有明确的预期：“goroutine可以及时完成任务或者解释为什么不能及时完成，另外必要情况下可以取消任务。”
以下几点请记住：
- WithTimeout 其实就是换了个名字的 WithDeadline。
- 最近更新的 Go（版本 1.20 和 1.21）中添加的 XXXCause 函数提供了更好的错误报告。
- 如果
XXXCause发生超时，它会提供更详细的错误消息：“context deadline exceeded: custom message.”
“channels怎么样？我不想在channel上永久等待。”
为了确保不会无限等待处理channels，更好的管理方法是使用 select 语句，它允许我们设置超时选项：
select{case result := <-ch：fmt.Println("Received result:", result)case <-time.After(5*time.Second):fmt.Println("Timed out")
}
不过需要注意：使用 time.After 可能会导致短期内存泄露。在某些情况下，使用time.Timer 或 time.Ticker 可能更有效，因为它们能让我们更好地控制时间。
译者补充：关于 time.After 可能导致内存泄露的文章，可参考学习：
本文将在接下来技巧中深入探讨替代方案及其价值。
2. 不幸得是，context.Value 不是我们的朋友
context.Value 似乎是一个方便的工具，因为它可以在 context 中携带一些数据，然后在需要的地方取出这些数据。
这会让我们的函数签名简介明了，不是吗？典型的例子是这样的：
func A(ctx context.Context, transactionID string){payment := db.GetPayment(ctx, transactionID)ctx := context.WithValue(ctx, "payment", payment)B(ctx)
}func B(ctx context.Context){...C(ctx)
}func C(ctx context.Context){payment, ok := ctx.Value("payment").(payment)...
}
在这段代码中，函数 A 获取付款记录并将其添加到 context 中， 在 B 内调用的函数 C 检索此付款。这种方法避免直接通过函数 B 传递付款记录，该函数不需要了解付款。
此方法看起来不错，因为：
- 允许我们省略函数传递特定不使用的数据，就像 B 函数一样。
- 允许将必要的数据保存在 context 中。
- 避免函数签名中的额外参数。
为什么不在函数中 A 中直接调用函数 C 呢？通常情况下，C与B的逻辑结合得很深，可能依赖它的某些计算和参数。
那么问题出在哪里呢？问题就出在这里：
- 放弃了Go在编译过程中提供的类型检查安全性。
- 我们将数据放入黑匣子中并希望以后能再找到它，而一周之后可能就像盲人搜索一样。
- 由于隐士传递，付款数据似乎可有可无，但实际上非常重要。
从个人角度来看，使用 ctx.Value 的主要问题在于它如何隐藏数据。这就像把东西放在一个没有明确标签的保险箱里。当然，数据被保存起来了，但检索数据却成了一个猜谜游戏。
明确我们正在传递的消息通常会减少以后的麻烦。
“那么，什么时候适合使用 context.Value() ?”
最好限制它的使用范围，但 Go 文档建议在跨API和进程间传递请求范围的值时使用它。以下是一些很好的用途：
你可以考虑使用它来跟踪某些与请求相关的数据，例如：
- 跟踪请求的开始时间
- 记录访问者的IP地址
- 管理追踪和跨度IDs
- 识别正在访问的HTTP路由
- …
上面例子中 ‘payment’ 支付数据与请求无关吗？
如果 ‘payment’ 支付信息在多个函数中都很重要，那么在函数参数显示传递它会更清晰、安全，并且有助于任何阅读代码的人立即理解该函数直接与‘payment’支付数据交互。
一般来说，最好避免在 context 中嵌入关键业务数据，这种策略可以保持代码清晰度和可维护性。
3. 使用context.WithoutCancel 保持 context 活跃
当在Go中实用context时，非常简单的一件就是直接使用带有取消功能的context。如果取消父级context，所有子context也会被取消。
比如，下面这个简单的例子：
parentCtx, cancel := context.WithCancel(context.Background())
childCtx, _ := context.WithCancel(parentCtx)go func(ctx context.Context){<-ctx.Done()fmt.Println("Child context done")
}(childCtx)cancel()
此段代码中，一旦我们取消 parentCtx, childCtx 也会被取消。这通常是我们想要的，但有时我们可能需要一个子context能够继续运行，即使父级context被取消了。
在Go中处理HTTP请求时，我们会经常遇到一个场景：在处理主请求后启动goroutine处理任务，如果处理不仔细可能会导致错误：
func handleRequest(req *http.Request){ctx := req.Context()go hookAfterRequest(ctx)
}
在我们考虑处理HTTP请求时，即使客户端断开连接，我们仍然需要记录详细信息并收集指标，而不是取消运行。
未完待翻译，感兴趣可以先看原仓库英文版。喜欢给个鼓励 star ！
中文：Go实用技巧
英文：go-practical-tips
