Go http.Client 怎么为不同请求设置不同超时

同一个 Go 服务往往同时调用健康检查、普通查询和慢速报表接口，三者不应该共享同一个等待时间。做法是复用一个 http.Client，把较宽的总上限放在 Client.Timeout，再在每次请求上用 context.WithTimeout 设置独立预算。这样既保留连接池，也能让每个调用按业务速度失败。

推荐的组合是：共享一个配置过的 http.Client，每个请求创建自己的 Context；实际生效的截止时间取更早者。请求结束后要关闭并尽量读完 Response.Body，否则连接复用会受到影响。

先把两层超时职责分开

Client.Timeout 是这个客户端发出的每个请求的总时间限制，包含建立连接、重定向和读取响应体。它不是只限制“等响应头”的时间。请求级 Context 的覆盖范围也很完整：获取连接、发送请求以及读取响应头和响应体都受它控制。

初始化一个可以长期复用的 Client

先做一个很小的“上游请求巡检器”。健康检查、用户查询和报表调用都使用同一个 Client，只把连接与重定向等共性配置放在这里。官方文档明确说明 Client 可以被多个 goroutine 并发使用，Transport 内部还会缓存 TCP 连接，因此不要在每次调用里临时创建。

package main

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "time"
)

// sharedClient 只保存跨请求共享的策略，单次预算放到请求 Context。
var sharedClient = &http.Client{
    Timeout: 20 * time.Second, // 防止任意请求整体失控
}

func requestWithTimeout(ctx context.Context, url string, timeout time.Duration) error {
    requestCtx, cancel := context.WithTimeout(ctx, timeout)
    defer cancel() // 无论成功、失败还是超时，都释放定时器资源

    req, err := http.NewRequestWithContext(requestCtx, http.MethodGet, url, nil)
    if err != nil {
        return fmt.Errorf("创建请求: %w", err)
    }

    resp, err := sharedClient.Do(req)
    if err != nil {
        return fmt.Errorf("请求 %s: %w", url, err)
    }
    defer resp.Body.Close() // 调用方负责关闭成功响应的 Body

    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return fmt.Errorf("读取响应体: %w", err)
    }
    if resp.StatusCode >= http.StatusBadRequest {
        return fmt.Errorf("上游返回 HTTP %s", resp.Status)
    }
    return nil
}

这个函数里的 timeout 只影响当前请求。例如传入 800 毫秒和 8 秒，就能让两个接口拥有不同预算；如果某次请求的 Context 还剩 500 毫秒，函数内部再设置 8 秒也不会把父 Context 的截止时间往后延。Client.Timeout 为 20 秒时，它与请求 Context 共同生效，谁先到期谁负责取消。

让每个接口拥有自己的等待预算

调用时只需为不同任务传不同的时长。实际项目中可以把这些值放到配置文件，但要先明确它们代表的是“完整请求预算”，不是服务端一定会在这个时间内完成。

func runChecks(ctx context.Context) error {
    // 探活只需要快速得到状态，失败应尽快暴露。
    if err := requestWithTimeout(ctx, "https://api.example.com/health", 800*time.Millisecond); err != nil {
        return fmt.Errorf("健康检查失败: %w", err)
    }

    // 普通查询给网络抖动留出更多空间。
    if err := requestWithTimeout(ctx, "https://api.example.com/orders", 3*time.Second); err != nil {
        return fmt.Errorf("订单查询失败: %w", err)
    }

    // 报表可能涉及聚合，但仍受 Client.Timeout 的 20 秒兜底保护。
    return requestWithTimeout(ctx, "https://api.example.com/report", 12*time.Second)
}

如果上游返回 500，Do 通常仍会得到一个非空响应和 nil 错误，所以代码要单独检查 StatusCode。网络失败、重定向策略失败或 Context 到期才会进入错误分支。不要只依据错误字符串判断超时，可用 errors.Is(err, context.DeadlineExceeded) 检查 Context 截止，也可以对包装后的 url.Error 使用其 Timeout() 方法。

用清晰的边界完成验收

验收时不要只看“是否超时”。先把每类调用的预算写成表，再观察错误属于父 Context、请求 Context 还是 Client 总上限。若代码在返回成功后没有读完并关闭 Body，后续请求可能无法充分复用持久 TCP 连接；如果只想限制响应头等待时间，再考虑 Transport.ResponseHeaderTimeout，不要误把它当作整个请求的超时。

• 健康检查：短请求预算，超时后快速让上层知道实例不可用。
• 普通查询：覆盖常态网络延迟，仍由 Client 总上限兜底。
• 慢速报表：给足业务允许的时间，但必须设置明确上限，不能把 0 当成“无限等待”的生产策略。
• 响应处理：检查 HTTP 状态，读取需要的内容，最后关闭 Body。

常见问题

能不能为每个请求复制一个 http.Client？

可以运行，但通常没有必要。频繁创建会失去共享 Transport 的连接复用优势；更合适的做法是复用 Client，用请求级 Context 区分预算。

Client.Timeout 和 Context.Timeout 谁优先？

两者都在约束请求，实际截止时间取更早者。父 Context 的截止时间也会继续约束子 Context。

超时后还要关闭 Response.Body 吗？

如果 Do 已经返回了响应，就按正常路径处理并关闭 Body；如果只返回错误而没有响应，不需要访问不存在的 Body。