Go语言使用Context控制超时在网络语言学习中的应用

context是Go控制并发任务生命周期的机制，用于超时、取消和信号传播；HTTP超时必须用context.WithTimeout配合http.Client，且需显式监听ctx.Done()。

先澄清一个误区：context 跟“网络用语”“语言学习”八竿子打不着。它是 Go 标准库里专门用来控制并发任务生命周期的利器，核心就三件事：超时、取消、信号传播。

如果你看到“网络语言学习”这种说法，多半是把“网络请求”（network request）和“网络用语”（internet slang）搞混了。下面直接上干货，只讲真实开发里必须搞清楚的细节。

HTTP 客户端超时必须用 context.WithTimeout，不能只靠 http.Client.Timeout

不少人觉得只要设了 http.Client.Timeout 就稳了，其实不然：

• http.Client.Timeout 只管连接建立和响应头读取，响应体读取（比如大文件下载卡在 resp.Body.Read）它完全不管。
• context.WithTimeout 能覆盖整个请求生命周期：DNS、连接、TLS、写请求、读响应头、读响应体，一个不落。
• 两者配合用最好，但 context 更可靠，控制粒度也更细。

正确写法长这样：

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

req, _ := http.NewRequest("GET", "https://example.com/api", nil)
req = req.WithContext(ctx)

client := &http.Client{}
resp, err := client.Do(req)
if err != nil {
    // 这里 err 可能是 context.DeadlineExceeded
    return
}
defer resp.Body.Close()

ctx.Done() 必须被显式监听，否则超时不会中断正在运行的 goroutine

派生了 context.WithTimeout 之后，如果不主动检查 ctx.Done()，goroutine 照样跑完，资源照样泄漏——超时就成了摆设。

• 数据库查询别用 db.Query，换成 db.QueryContext。
• 自定义长任务（比如解析大 JSON、压缩文件）必须在循环里加 select 或定期检查 ctx.Err() != nil。
• 不要把 ctx 存在 struct 字段里；它必须作为第一个参数传入函数，保证调用链可追溯。

错误示例（超时后仍继续执行）：

go func() {
    time.Sleep(10 * time.Second) // 完全无视 ctx
    fmt.Println("done")
}()

正确做法：

go func() {
    select {
    case <-time.After(10 * time.Second):
        fmt.Println("done")
    case <-ctx.Done():
        fmt.Println("canceled:", ctx.Err()) // 输出 context.DeadlineExceeded
        return
    }
}()

cancel() 必须 defer 调用，否则会导致 context 泄漏

context.WithTimeout 和 context.WithCancel 返回的 cancel 函数不是可选项——它是资源清理的关键一环。

• 没调用 cancel()，父 context 的子节点不会被 GC，内存持续增长。
• 即使超时已触发，也要调用 cancel()，否则 Done() channel 不会释放。
• 常见坑：在 error early return 前忘了 cancel()，建议统一用 defer cancel()。

反模式：

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
if someCondition {
    return // cancel 没被调用！
}
defer cancel() // 这行永远执行不到

超时错误判断别用字符串匹配，用 errors.Is(err, context.DeadlineExceeded)

日志或重试逻辑里，经常有人写 strings.Contains(err.Error(), "deadline") ——这不可靠。

• context.DeadlineExceeded 是导出变量，类型是 error，用 errors.Is 精确判断最稳妥。
• 不同 Go 版本、不同 HTTP 库返回的错误信息可能变化，但 context.DeadlineExceeded 始终稳定。
• 注意：context.Canceled 是另一类错误（主动取消），和超时不等价。

推荐写法：

if errors.Is(err, context.DeadlineExceeded) {
    log.Warn("request timeout", "url", url)
    return
}

真正难的不是写对那几行 context.WithTimeout，而是确保每个下游调用都接收并响应 ctx 参数，且所有阻塞操作都受其约束。漏掉一个 db.Query 没换成 db.QueryContext，整个超时控制就形同虚设。