不是必须，但仅靠 http.Client.Timeout 无法覆盖 DNS 解析、TLS 握手、连接池等待等前置超时；必须用 context.WithTimeout 传入 request 才能真正可控、可取消、可组合地管理全链路超时。
Go 中 http.Client 超时必须用 context.Context 吗？
不是必须，但仅靠 http.Client.Timeout 无法覆盖所有超时场景。比如你设置了 Client.Timeout = 5 * time.Second，它只控制「整个请求从开始到响应体读完」的总耗时，但不包括 DNS 解析、TLS 握手、连接池等待等前置阶段。这些阶段卡住时，Timeout 不生效，请求可能 hang 住十几秒甚至更久。
真正可控、可取消、可组合的超时，得靠 context.WithTimeout 或 context.WithDeadline 配合 http.Request.WithContext。这是 Go 官方推荐的现代写法。
-
http.Client.Timeout适合简单脚本或内部短链调用，别用于对外服务或高可靠性场景 - 生产环境 HTTP 请求，一律优先用
context控制生命周期 - 同一个
context可同时约束多个 I/O 操作（如先发请求，再异步处理响应），这是纯Timeout做不到的
如何用 context.WithTimeout 正确包裹 http.NewRequest
关键点：不是把 context 传给 http.Client.Do，而是传给 *http.Request 本身。Client 只负责执行带 context 的 request。
常见错误是直接对 Do() 加 timeout 包裹（比如用 time.AfterFunc 手动 cancel），这会导致连接泄漏、goroutine 泄漏，且无法中断正在发生的底层网络操作。
立即学习“go语言免费学习笔记（深入）”；
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel() // 必须 defer，否则可能泄露req, err := http.NewRequestWithContext(ctx, "GET", "https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca", nil) if err != nil { log.Fatal(err) }
client := &http.Client{} resp, err := client.Do(req) // client 尊重 req.Context() if err != nil { if errors.Is(err, context.DeadlineExceeded) { log.Println("request timed out") } else { log.Printf("request failed: %v", err) } return } defer resp.Body.Close()
- 务必调用
cancel()，哪怕只是 defer —— 否则 context 不会释放，底层 TCP 连接可能持续等待 - 判断超时要用
errors.Is(err, context.DeadlineExceeded)，而不是字符串匹配"timeout"，因为不同阶段（DNS、connect、TLS）报错类型不同 - 不要复用同一个
context发起多个请求，每个请求应有独立的 context 实例
测试超时逻辑时，为什么本地 mock 总是不触发 context.DeadlineExceeded？
因为你 mock 的 handler 执行太快，根本没机会触发超时。真超时需要让 handler 主动 sleep 或阻塞，或者用不可达地址（如 http://10.255.255.1）触发底层 connect timeout —— 但这依赖系统网络栈，不稳定且难断言。
最可靠的方式是用 net/http/httptest + 显式延迟，并在测试中验证 error 类型：
func TestRequestTimeout(t *testing.T) {
server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
time.Sleep(100 * time.Millisecond) // 故意拖慢
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
}))
defer server.Close()
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Millisecond)
defer cancel()
req, _ := http.NewRequestWithContext(ctx, "GET", server.URL, nil)
resp, err := http.DefaultClient.Do(req)
if !errors.Is(err, context.DeadlineExceeded) {
t.Fatalf("expected context.DeadlineExceeded, got %v", err)
}
if resp != nil {
t.Error("expected nil response on timeout")
}}
- 别用
time.Sleep在测试里“等超时”，而是让 handler 睡眠，迫使 client 主动 cancel - 检查
resp == nil是必要步骤 —— 超时发生时，Do()返回非 nil error 且resp为 nil - 避免在测试中用真实外网地址，DNS 和网络抖动会让测试 flaky
HTTP/2 和连接复用下，context 超时还可靠吗？
可靠，但要注意：HTTP/2 的多路复用特性会让多个请求共享一个 TCP 连接，而 context 取消只影响当前 request，不会中断其他正在该连接上进行的流（stream）。也就是说，A 请求超时 cancel，不会导致 B 请求被连带中断。
不过有个隐藏坑：http.Transport 默认启用 keep-alive 和连接池，如果某个请求因 context 超时被 cancel，其底层连接可能被标记为 “即将关闭”，但 Transport 不会立刻关掉它 —— 下次复用时，可能遇到 net/http: request canceled (Client.Timeout exceeded while awaiting headers) 这类二次错误。
- 可通过设置
Transport.IdleConnTimeout和Transport.MaxIdleConnsPerHost缓解连接复用污染 - 若业务对时延极度敏感，可在超时后主动调用
Transport.CloseIdleConnections()（谨慎使用，会影响其他并发请求） - HTTP/2 场景下，建议显式设置
Transport.ForceAttemptHTTP2 = true并监控http2.Transport的指标，避免误判超时来源
context 的 timeout 行为在 Go 1.18+ 更稳定，但 DNS 解析阶段仍可能略过 context 控制（尤其在使用 net.Resolver 自定义时），这点容易被忽略。
