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))
resp, 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。
立即学习“go语言免费学习笔记（深入）”；
- 永远用
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 后面
<p>if resp.StatusCode != 200 {
io.Copy(io.Discard, resp.Body) // 清空 body 避免连接滞留
return fmt.Errorf("bad status: %d", resp.StatusCode)
}</p><p>body, err := io.ReadAll(resp.Body)
if err != nil {
return err
}真正卡顿往往不在代码逻辑，而在 transport 层配置与网络环境的错配。trace 数据、连接复用率、超时分段、body 关闭——这四点串起来，80% 的 HTTP 性能问题都能定位到具体环节。别依赖 “感觉慢”，把每个阶段的时间数字打出来，比任何猜测都管用。
