17370845950

HTTP请求真实耗时需用httptrace.ClientTrace拆解DNS、TLS、连接、读写等各阶段；关键在Transport配置（复用、超时、Body关闭），而非仅看总耗时。

怎么看 HTTP 请求真实耗时在哪一环

Go 的 http.Client 默认不暴露各阶段耗时，光看 time.Since(start) 只能得到总时间，无法区分是 DNS、TLS、连接建立、写请求体、读响应头还是读响应体拖慢了。必须用 httptrace.ClientTrace 才能拆解。

• 所有关键阶段回调函数都接收 *httptrace.GotConnInfo、*httptrace.DNSDoneInfo 等结构，字段名直白，比如 ConnReused 能立刻判断是否复用了连接
• 注意 trace 回调在 goroutine 中执行，不要在回调里做阻塞操作（如写文件、打日志到磁盘），否则会拖慢整个 HTTP 流程
• 如果用的是自定义 http.Transport，确保它没禁用 trace——默认开启，但若手动设置了 Transport.DialContext 却没透传 ctx，DNS 和连接阶段 trace 会丢失

trace := &httptrace.ClientTrace{
    DNSStart: func(info httptrace.DNSStartInfo) {
        log.Printf("DNS start: %s", info.Host)
    },
    DNSDone: func(info httptrace.DNSDoneInfo) {
        log.Printf("DNS done: %+v", info)
    },
    ConnectStart: func(network, addr string) {
        log.Printf("Connect start: %s %s", network, addr)
    },
    GotConn: func(info httptrace.GotConnInfo) {
        log.Printf("Got conn: reused=%t, was_idle=%t, idle_time=%v", 
            info.Reused, info.WasIdle, info.IdleTime)
    },
}
req, _ := http.NewRequest("GET", "https://api.example.com/v1/data", nil)
req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
re
sp, err := http.DefaultClient.Do(req)

为什么连接复用没生效｜Transport 配置常见误配

即使启用了 trace，你也可能看到大量 ConnReused=false，说明连接没复用。这不是 Go 的 bug，而是 http.Transport 的几个关键字段被设得太保守或压根没配。

• MaxIdleConns 控制全局最多保持多少空闲连接；MaxIdleConnsPerHost 控制每个 host 最多保持多少——两者默认都是 100，但如果你设成 0 或 1，复用率会断崖下跌
• IdleConnTimeout 默认是 30s，但如果后端服务主动断连更快（比如 Nginx 的 keepalive_timeout 5s），客户端还傻等 30 秒才清理，下次请求就得新建连接
• 别忽略 ForceAttemptHTTP2：设为 false 且目标服务支持 HTTP/2 时，Go 可能降级走 HTTP/1.1，而 HTTP/2 天然多路复用，对高并发小请求更友好

client := &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        200,
        MaxIdleConnsPerHost: 200,
        IdleConnTimeout:     5 * time.Second, // 匹配后端 keepalive timeout
        ForceAttemptHTTP2:   true,
    },
}

超时设置错位导致请求卡死几十秒

很多人只设 http.Client.Timeout，以为万事大吉。但这个 timeout 是“从 Do 开始到响应 body 读完”的总时限，不覆盖 DNS 解析、TLS 握手等前置环节。结果就是：DNS 被污染卡住、服务端 TLS 证书异常、中间代理僵死——这些都会让请求挂满默认的 30 秒（甚至更久），而 Timeout 根本没触发。

• 必须分开设：用 http.Transport.DialContext 控制拨号（含 DNS + TCP 连接）超时；用 TLSHandshakeTimeout 控制 TLS 握手；再用 ResponseHeaderTimeout 限制从连接建立到收到响应头的时间
• ExpectContinueTimeout 容易被忽略：当请求体较大且服务端支持 100-continue 时，客户端会先发 header 等确认，这个等待也有超时，默认 1s，太短可能误判，太长又拖慢 POST
• 所有超时值建议设为同一量级（比如 3–5 秒），避免某一个环节拖垮整体 SLA

transport := &http.Transport{
    DialContext: (&net.Dialer{
        Timeout:   3 * time.Second,
        KeepAlive: 30 * time.Second,
    }).DialContext,
    TLSHandshakeTimeout:   3 * time.Second,
    ResponseHeaderTimeout: 3 * time.Second,
    ExpectContinueTimeout: 1 * time.Second,
}

Body 没关闭引发 fd 耗尽和内存泄漏

这是最隐蔽也最致命的性能坑：resp.Body 不关，底层连接不会归还给连接池，fd 持续增长，最终 dial tcp: lookup xxx: no such host 或 too many open files 报错。而且 Go 1.19+ 对未读完的 body 会自动缓冲到内存，大响应体直接 OOM。

• 永远用 defer resp.Body.Close()，哪怕你只读前几字节或直接丢弃响应
• 如果要用 ioutil.ReadAll 或 io.Copy，确保它们返回后再关；不要在 if err != nil 分支里漏掉 Close
• 用 resp.Body = http.NoBody 替代 nil，避免某些中间件误判；但真正要丢弃 body 时，仍需 io.Copy(io.Discard, resp.Body) 再关

resp, err := client.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close() // 必须放在这里，不是在 if 后面
if resp.StatusCode != 200 {
io.Copy(io.Discard, resp.Body) // 清空 body 避免连接滞留
return fmt.Errorf("bad status: %d", resp.StatusCode)
}
body, err := io.ReadAll(resp.Body)
if err != nil {
return err
}

真正卡顿往往不在代码逻辑，而在 transport 层配置与网络环境的错配。trace 数据、连接复用率、超时分段、body 关闭——这四点串起来，80% 的 HTTP 性能问题都能定位到具体环节。别依赖 “感觉慢”，把每个阶段的时间数字打出来，比任何猜测都管用。