如何使用Golang模拟请求超时_Golang context与HTTP请求测试实践

不是必须，但仅靠 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 泄漏，且无法中断正在发生的底层网络操作。

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel() // 必须 defer，否则可能泄露
req, err := http.NewRequestWithContext(ctx, "GET", "https://www./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 自定义时），这点容易被忽略。

# go # golang # 栈 # ai # keep-alive # dns # stream # 并发请求 # 为什么 # while # Error # 字符串 # nil # 并发 # 异步 # http # 复用 # 多个 # 这是 # 会让 # 连接池 # 仅靠 # 有个 # 为你 # 可取消 # 并在