httpClient请求偶发一直等待怎么办

Go 的 http.Client 请求偶尔一直等待，最常见的根因不是“网络偶尔慢”这么简单，而是客户端没有给整次请求设置截止时间，或者只给某一个阶段设置了超时。连接建立、TLS 握手、等待响应头、读取响应体都可能分别停住。

官方文档：https://pkg.go.dev/net/http

先判断是哪里在等待

把“请求没返回”分成四段，排查方向会清楚很多：拨号阶段可能受 DNS、代理或连接池限制影响；TLS 阶段可能卡在握手；请求写完后可能长时间收不到响应头；拿到响应头后，服务端也可能迟迟不结束响应体。ResponseHeaderTimeout 只覆盖等待响应头，不覆盖后续读取响应体；而 Client.Timeout 覆盖连接、重定向和响应体读取。

因此，先不要把所有异常都改成“重试三次”。如果调用方的 Context 已经取消，继续重试只会放大上游压力；如果是响应体读取阶段，单独调大响应头超时也不会解决问题。

给整次事务和单次调用都设置截止时间

适合长期复用的 Client 可以设置一个总预算，单次请求再根据业务重要性缩短或继承调用方的截止时间。下面的代码只展示请求边界与错误分类，示例中的地址可以替换成自己的服务。

package main

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

// 复用同一个 Client，让 Transport 有机会复用连接；总超时覆盖整次事务。
var client = &http.Client{
    Timeout: 15 * time.Second,
}

func fetch(ctx context.Context, url string) ([]byte, error) {
    // 单次调用的预算不能超过上游已经给出的 ctx 截止时间。
    reqCtx, cancel := context.WithTimeout(ctx, 8*time.Second)
    defer cancel() // 提前返回时释放定时器和派生 Context 资源。

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

    resp, err := client.Do(req)
    if err != nil {
        // 超时可能来自 Context，也可能是底层网络错误；保留原始错误链。
        if errors.Is(err, context.DeadlineExceeded) {
            return nil, fmt.Errorf("HTTP 请求超时: %w", err)
        }
        var netErr net.Error
        if errors.As(err, &netErr) && netErr.Timeout() {
            return nil, fmt.Errorf("网络阶段超时: %w", err)
        }
        return nil, fmt.Errorf("HTTP 请求失败: %w", err)
    }
    defer resp.Body.Close() // 无论状态码如何，都要关闭响应体。

    if resp.StatusCode = 300 {
        return nil, fmt.Errorf("上游返回状态码 %s", resp.Status)
    }
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        // Client.Timeout 或 reqCtx 也可能在读取响应体时触发。
        return nil, fmt.Errorf("读取响应体失败: %w", err)
    }
    return body, nil
}

这里的两个时间不是简单相加：如果父 Context 剩余时间只有 3 秒，派生的 8 秒 Context 仍会在父 Context 截止时提前结束。defer cancel() 则负责在请求提前成功时释放定时器关联资源。

需要分阶段定位时配置 Transport

当日志已经说明问题集中在连接、TLS 或响应头阶段，可以在复用的 Transport 上补边界。不要每次请求都新建 Transport；Transport 内部维护连接状态，并且可以安全地并发复用。

package main

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

// Transport 的各项时间用于缩小故障阶段；Client.Timeout 仍负责总预算。
var diagnosticClient = &http.Client{
    Timeout: 15 * time.Second,
    Transport: &http.Transport{
        // 拨号超时覆盖建立 TCP 连接的等待。
        DialContext: (&net.Dialer{
            Timeout: 3 * time.Second,
            KeepAlive: 30 * time.Second,
        }).DialContext,
        // HTTPS 握手迟迟不完成时，不要无限等待。
        TLSHandshakeTimeout: 3 * time.Second,
        // 请求体写完后，限制等待首个响应头的时间。
        ResponseHeaderTimeout: 5 * time.Second,
        // 空闲连接失效后及时清理，减少复用陈旧连接的干扰。
        IdleConnTimeout: 90 * time.Second,
    },
}

func requestWithContext(ctx context.Context, url string) (*http.Response, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return nil, err
    }
    return diagnosticClient.Do(req)
}

这组参数不是通用的“越小越好”模板：拨号和 TLS 时间要结合跨地域网络，响应头时间要结合上游接口的正常尾延迟。若接口是流式响应，响应头返回后可能持续读取很久，此时应使用请求 Context、Client 总超时或业务层的空闲读取策略，而不是误以为 ResponseHeaderTimeout 会限制整条响应。

响应体必须关闭，Client 不要按请求创建

拿到 resp 不代表事务已经完成。读取完响应体后关闭 resp.Body，即使状态码是 404 或 500 也一样；否则连接池可能无法按预期复用，长期运行时会表现为连接数增长、后续请求排队或资源耗尽。

同样，http.Client 和 http.Transport 应作为长期对象复用。官方文档说明 Client 与 Transport 都可以被多个 goroutine 并发使用；每次请求临时创建一套对象，会丢掉连接缓存，也让连接建立的等待更频繁。

常见问题

为什么设置了 ResponseHeaderTimeout 还是会一直等

它只限制请求体写完后等待响应头的时间，不限制拿到响应头之后读取响应体的时间。要限制整次请求，应同时设置 Client.Timeout 或请求 Context。

http.Get 默认有超时吗

不要把默认 Client 当作生产超时策略。零值 Client 可用，但 Timeout 为零表示不设置总超时；应显式创建并复用带截止时间的 Client。

超时后应该马上重试吗

先区分调用方取消、连接阶段超时、上游响应慢和响应体读取超时。只有业务允许且有退避、次数和总预算时才重试，否则可能把一个慢接口放大成重试风暴。

为什么错误里有 context deadline exceeded

它说明 Context 的截止时间已到，可能是请求级 Context，也可能是 Client 总超时触发的取消。保留错误链并记录阶段、目标和耗时，才能继续定位根因。

解决 Go http.Client 偶发一直等待的关键，是建立“总预算 + 单次 Context + 分阶段 Transport 边界”的三层保护，再配合响应体关闭和 Client 复用。这样超时会成为可记录、可分类的错误，而不是一个无法解释的卡死现象。