超时控制必须使用 context.Context，不能仅依赖 time.After；正确做法是用 context.WithTimeout 或 context.WithDeadline，以支持取消和信号传播，避免 goroutine 泄漏。
超时控制必须用 context.Context，不能只靠 time.After
直接用 time.After 启动 goroutine 等待超时，无法取消上游操作，容易造成 goroutine 泄漏。真正可控的超时必须基于 context.WithTimeout 或 context.WithDeadline，因为它们返回的 context.Context 支持主动取消和传播取消信号。
常见错误写法：
go func() {
select {
case <-time.After(5 * time.Second):
fmt.Println("timeout")
case result := <-ch:
fmt.Println("got", result)
}
}()这个例子中，即使 ch 很快返回，time.After 的 timer 仍会运行完，且 goroutine 无法被外部中断。
正确做法是统一用 context 控制生命周期：
立即学习“go语言免费学习笔记（深入）”；
-
context.WithTimeout(ctx, 5*time.Second)返回带超时的新ctx和cancel函数 - 所有下游操作（HTTP 请求、数据库查询、channel 等）都应接收该
ctx并监听ctx.Done() - 务必调用
cancel()（尤其在提前返回时），否则 timer 不释放，可能堆积
http.Client 超时必须传入 context.Context，别只设 Timeout 字段
http.Client.Timeout 只控制整个请求的总耗时（从开始到响应 body 读完），但无法中断 DNS 解析、TLS 握手、连接建立等前置阶段。而 context.Context 能在任意阶段响应取消信号，更精准可靠。
典型误用：
client := &http.Client{Timeout: 3 * time.Second}
resp, err := client.Get("https://example.com") // DNS 卡住？TLS 拖延？它不管推荐组合方式：
- 设置较短的
http.Client.Timeout（如 10ms～100ms）仅作兜底，防止 context 漏传 - 每次请求都用
context.WithTimeout显式传入，例如：ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) - 调用
client.Do(req.WithContext(ctx))，确保底层 transport 尊重 context - 记得
defer cancel()，尤其在 error 分支也要调用，避免泄漏
自定义 I/O 操作如何接入 context.Context
标准库中很多函数（如 net.Conn.Read、os.File.Read）不接受 context.Context，需手动包装。核心思路是：用 ctx.Done() 触发中断，再通过 conn.SetReadDeadline 或 select 配合 chan 实现非阻塞等待。
例如对 net.Conn 做上下文感知读取：
func readWithContext(conn net.Conn, b []byte, ctx context.Context) (int, error) {
done := make(chan struct{})
go func() {
_, _ = conn.Read(b) // 忽略错误，由主流程判断
close(done)
}()
select {
case <-done:
return len(b), nil
case <-ctx.Done():
conn.SetReadDeadline(time.Now().Add(-1 * time.Second)) // 强制唤醒阻塞 Read
return 0, ctx.Err()
}
}注意点：
- 不要在 goroutine 中忽略
conn.Read错误，实际应转发到 channel 或用 sync.Once 清理 -
SetReadDeadline是关键，否则Read会一直阻塞，ctx.Done()无法生效 - 若使用
bufio.Reader，需确保其底层io.Reader支持 deadline，否则要换用bufio.NewReaderSize+ 自定义 wrapper
time.AfterFunc 不能替代 context.WithTimeout
time.AfterFunc 只是定时触发一个函数，它不产生可传递、可取消、可组合的取消信号。而 context.Context 是树状结构，子 context 可继承父 context 的取消状态，适合嵌套调用场景。
比如你启动一个 HTTP 请求，它内部又调用 Redis 查询，Redis 查询又依赖另一个 gRPC 调用——这时只有 context 能逐层穿透取消信号。用 AfterFunc 只能在最外层“硬杀”，中间环节无法响应。
另外：time.AfterFunc 创建的 timer 不会自动 GC，如果 handler 没执行完就丢弃引用，timer 仍会运行并触发 handler（可能 panic 或写已释放内存）。而 context.WithTimeout 的 timer 在 cancel() 调用后会被 runtime 回收。
所以记住：
- 单次延迟执行 → 可用
time.AfterFunc（但记得保存返回的*Timer并显式Stop()） - 需要取消、传播、组合、监控的超时控制 → 必须用
context.WithTimeout或WithDeadline - 多个并发操作共用同一超时 → 复用同一个
ctx，不要为每个操作新建
最易被忽略的是：cancel() 必须在所有路径上调用，包括 return 前、if err != nil 分支、甚至 panic 恢复后——漏掉一次，就多一个泄漏的 timer 和 goroutine。
