Transport空闲连接复用不稳定怎么办

Go 的 Transport 复用不稳定，第一反应不要先把 MaxIdleConnsPerHost 调得很大。更常见的根因是响应体没有正确关闭、每次请求都新建 Client 或 Transport，以及代码主动设置了关闭连接的选项。排查时按“响应体是否释放 → Transport 是否共享 → 空闲池是否够用 → 是否被主动关闭”的顺序看，通常比盲目改参数更快。

先把“不复用”拆成三个不同现象

看到服务端连接数不断增加，或者每次请求都像重新握手，至少有三种解释：响应体还没有释放，连接根本没机会回到空闲池；空闲连接回来了，但每个主机的保留上限太小；连接确实进入过空闲池，随后又被空闲超时、对端关闭或主动关闭策略淘汰。它们的修复动作并不一样。

官方文档说明，Transport 会缓存连接供后续请求复用，而且应当复用而不是按请求创建。Transport 处理的是底层传输，Client 还负责重定向、Cookie 等更高层策略；两者的生命周期都应该覆盖一组请求，而不是只覆盖一个函数调用。

先保证响应体真的回到可复用边界

如果 Do 返回成功，调用方就拥有关闭响应体的责任。只调用 Close 而没有消费响应内容，并不能让所有场景都拥有同样的复用效果；对 HTTP/1.x 请求，读到 EOF 后再关闭更容易明确地完成响应消费。响应体属于本次请求，不能因为只关心状态码就遗忘它。

package client

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

var sharedClient = &http.Client{
    Transport: &http.Transport{
        // 共享 Transport，让后续请求有机会使用同一主机的空闲连接。
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 20,
        IdleConnTimeout:     90 * time.Second,
    },
    Timeout: 10 * time.Second,
}

func fetch(ctx context.Context, url string) ([]byte, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return nil, err
    }

    resp, err := sharedClient.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close() // 无论后续解析是否出错，都要释放响应体。

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, fmt.Errorf("read response body: %w", err)
    }
    if resp.StatusCode = 300 {
        return nil, fmt.Errorf("unexpected status: %s", resp.Status)
    }
    return body, nil
}

这里的关键不在于某个固定数字，而在于三个生命周期动作：共享一个客户端、每次成功响应都关闭 Body、需要判断内容时先读取再解析。如果业务只需要状态码，也可以按协议读取或丢弃响应内容，但仍然要关闭 Body。

用三个 Transport 参数区分容量与寿命

MaxIdleConns 是所有主机共享的空闲连接上限；MaxIdleConnsPerHost 是单个主机的空闲连接上限；IdleConnTimeout 是一条空闲 keep-alive 连接能保持多久。前两个解决“空闲连接太少”，最后一个解决“空闲连接是否应该过期”，它们不是同一个开关。

例如客户端同时访问很多上游服务时，全局上限可能先被耗尽；只有一个热点主机时，每主机上限更值得关注。参数调大也不是越大越好：连接长期占用文件描述符，服务端或中间代理的 keep-alive 策略也可能更短。应该根据请求并发、主机数量和对端空闲超时来设置，并把连接建立失败与响应读取失败分开记录。

主动关闭会让复用看起来“不稳定”

Request.Close = true 会阻止请求之间复用 TCP 连接，效果类似于对这次请求关闭 keep-alive；Transport.DisableKeepAlives 则让 Transport 不使用 HTTP keep-alive。它们适合明确的隔离或兼容场景，不适合当作常规排障开关长期保留。

CloseIdleConnections 的语义也要看清：它关闭的是已经处于空闲状态的连接，不会中断正在使用的连接。服务重载、切换代理或证书配置时可以主动调用，但如果业务代码在每个请求后都调用它，下一次请求自然就没有可复用的空闲连接了。

一份可执行的排查清单

• 先确认所有成功响应都走到了 Body.Close，需要复用时不要过早中断响应读取。
• 确认没有在请求函数内部创建新的 http.Client 或 http.Transport。
• 检查请求是否设置了 Close，Transport 是否启用了 DisableKeepAlives。
• 按主机数量和并发量分别看 MaxIdleConns 与 MaxIdleConnsPerHost，再看 IdleConnTimeout。
• 只有在切换资源或服务退出时调用 CloseIdleConnections，不要把它放进普通请求路径。

常见问题

只调用 resp.Body.Close 还不够吗？

关闭是必须动作，但如果希望 HTTP/1.x 连接更稳定地回到复用路径，通常还要让响应体被完整消费；是否需要读取全部内容取决于接口响应大小和业务处理方式。

MaxIdleConnsPerHost 调大后为什么仍然重新建连？

它只限制空闲连接保留数量，不能修复未关闭的响应体、请求级 Close、DisableKeepAlives、对端主动断开或 IdleConnTimeout 到期。

CloseIdleConnections 会不会影响正在执行的请求？

官方语义是关闭已处于空闲状态的连接，不中断当前正在使用的连接；但调用后新请求需要重新建立可用连接。