连接池参数

如果 Go 客户端的请求看起来“每次都在重新连接”，先别急着把所有连接池参数一起调大。net/http.Transport 的 IdleConnTimeout 只决定 keep-alive 连接在空闲池里最多保留多久；它设置得过短时，连接还没等到下一次请求就被清理，下一次请求自然更容易重新拨号，延迟也会跟着抖动。排查的关键是观察连接复用信号，而不是只看请求耗时。

先划清 IdleConnTimeout 的作用边界

一个请求完成后，连接可能回到 Transport 的空闲池，等待同一主机的后续请求。IdleConnTimeout 针对的是这段“空闲等待时间”，不是建立连接的超时，也不是服务端响应头超时。值为 0 表示不设置这一项的时间限制。

tr := &http.Transport{
    // 空闲 keep-alive 连接超过这个时间后会被清理。
    IdleConnTimeout: 30 * time.Second,
    // 控制每个主机最多保留多少条空闲连接，不等同于超时时间。
    MaxIdleConnsPerHost: 10,
}

client := &http.Client{Transport: tr}
// Transport 应在多个请求之间复用，避免每次请求重新创建连接池。
resp, err := client.Get(url)

这里最容易混淆的是三个边界：MaxIdleConnsPerHost 限制数量，MaxConnsPerHost 限制拨号中、活跃和空闲连接的总数，而 IdleConnTimeout 限制空闲连接的存活时间。只把数量调大，不能挽救一个过短的空闲时间。

用连接复用信号确认症状

要确认问题是否真的来自空闲连接过早失效，可以给单次请求挂上 httptrace.ClientTrace。GotConnInfo 中的 Reused、WasIdle 和 IdleTime 能帮助你区分“复用了池中连接”和“重新建立了连接”。下面的代码只记录观测点，不把某一条日志直接当成结论。

trace := &httptrace.ClientTrace{
    GotConn: func(info httptrace.GotConnInfo) {
        // Reused=false 通常表示本次没有拿到可复用的旧连接。
        log.Printf("reused=%t wasIdle=%t idle=%s", info.Reused, info.WasIdle, info.IdleTime)
    },
}

req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
if err != nil {
    return err
}
// 把 trace 放入请求上下文，Transport 才能回调 GotConn。
req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
resp, err := client.Do(req)
if err != nil {
    return err
}
// 读完并关闭响应体，连接才有机会回到空闲池。
defer resp.Body.Close()

如果请求间隔明显长于当前的 IdleConnTimeout，随后多次看到 Reused=false，而直接连续请求时更容易出现复用，这个对比就支持“空闲时间过短”的判断。反过来，如果请求一直并发、连接总数触碰上限，应该继续看 MaxConnsPerHost 和服务端容量，不能把所有新建连接都归咎于 IdleConnTimeout。

把空闲超时与相邻参数分开

排查时按下面的顺序更省时间：先确认所有请求是否共用同一个 http.Client 或 Transport；再确认响应体是否完整读取并关闭；然后才看 IdleConnTimeout 与请求间隔的关系。若代码把 Transport 写在请求函数内部，即使超时时间很长，也会因为连接池每次都是新的而失去复用。

DisableKeepAlives=true 会直接禁止跨请求复用，不能用来“修复”空闲超时；MaxIdleConnsPerHost 太小则更像是空闲连接数量不够；MaxConnsPerHost 太小会让拨号等待变明显。这些现象需要通过 GotConn 的信息和并发模式分开判断。

按上下游策略调整 Transport

调整值时不要照搬一个固定数字。先估计同一主机两次请求之间的常见空闲间隔，再对照服务端、反向代理或负载均衡器的 keep-alive 策略，给客户端留出可复用的窗口，同时避免让客户端长期持有已经可能被上游关闭的旧连接。

var sharedTransport = &http.Transport{
    // 让连接在典型请求间隔内仍有机会被复用。
    IdleConnTimeout: 2 * time.Minute,
    // 为热点主机保留适量空闲连接，数量与并发规模匹配。
    MaxIdleConnsPerHost: 20,
}

var sharedClient = &http.Client{
    // 全局复用 Client 和 Transport，避免连接池随请求反复创建。
    Transport: sharedTransport,
    Timeout:   15 * time.Second,
}

这段配置只是边界示例，不代表所有服务都应该使用两分钟。真正的修复标准是：空闲间隔较短的请求能稳定复用；空闲时间明显超过策略后，连接被清理也是可接受的；请求总超时仍由 Client.Timeout 或上下文负责。

反向检查：调整后看什么

修改后可以用同一组请求间隔再次观察 GotConn：短间隔请求应更常出现 Reused=true，而跨过空闲窗口后的第一次请求重新建连属于预期。若所有请求仍然新建，优先检查 Transport 是否被重复创建、响应体是否关闭，以及是否有中间层主动关闭连接。

• Transport 是否在请求之间复用。
• 响应体是否读完并关闭。
• IdleConnTimeout 是否短于真实请求间隔。
• MaxIdleConnsPerHost 是否满足同一主机的并发需求。
• 服务端或负载均衡器是否有更短的 keep-alive 策略。

相关问题

IdleConnTimeout 设置为 0 就一定最好吗？

不一定。它只是不限制客户端因空闲时间主动清理，连接仍可能被服务端、中间层或其他连接上限关闭。应结合上下游策略和资源规模决定。

为什么调大 MaxIdleConnsPerHost 后仍然频繁建连？

数量上限和空闲时长是两件事。如果连接在回到池后很快就超过 IdleConnTimeout，增加数量不会延长它的寿命；还要检查 Transport 是否被重复创建。

总结来说，“连接池参数”不是一个需要盲调的总开关。先用 httptrace 看复用信号，再把空闲时长、空闲数量、总连接上限和上下游 keep-alive 分开判断，才能把频繁建连定位到真正的边界。