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，整个超时控制就形同虚设。
