Go net/http.Transport 资源没有释放为什么

Go 里看到连接数不断上升、文件描述符逼近上限，或者抓到很多 keep-alive 连接时，不要先把 http.Transport 认定为“泄漏”。Transport 本来就会缓存连接以便复用；真正常见的问题是 Response.Body 没有关闭、响应体没有按需要读完，或者临时创建了太多没有统一生命周期的 Transport。

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

先判断泄漏发生在响应体还是连接池

http.Transport 默认会缓存连接，目的是让后续请求复用 TCP 连接。官方文档也明确建议复用 Transport，而不是每次请求都创建一个新的实例。因此，进程里存在一些 idle keep-alive 连接本身不等于泄漏。

排查时先把现象拆成三类：请求仍在进行的是活动连接；请求已结束、等待复用的是空闲连接；连接仍在拨号或握手阶段的是建立中连接。真正应该优先检查的是每条成功响应的 Body 是否都走到了关闭路径：

resp, err := client.Do(req)
if err != nil {
    // 没有拿到可交给业务处理的响应体，直接保留错误上下文。
    return fmt.Errorf("do request: %w", err)
}
defer resp.Body.Close()

// 状态码是 HTTP 响应的一部分，不能因为 404 或 503 就跳过 Body 关闭。
if resp.StatusCode >= 400 {
    return fmt.Errorf("upstream status: %s", resp.Status)
}
return nil

把 Response.Body 生命周期收紧

只写 defer resp.Body.Close() 能解决最基本的资源释放问题，但如果希望 HTTP/1.1 持久连接被 Transport 复用，通常还要把响应体读到 EOF。业务只需要少量字段时，可以限制读取上限，再关闭 Body；不要为了“读完”把一个不受控的大响应全部加载进内存。

func readResponse(resp *http.Response) ([]byte, error) {
    defer resp.Body.Close()

    // 限制单次读取大小，避免异常响应把内存推高；上限按业务协议调整。
    const maxBody = 1  maxBody {
        // 超出上限时明确返回错误，不把截断内容当成完整结果。
        return nil, fmt.Errorf("response body exceeds %d bytes", maxBody)
    }
    return body, nil
}

审查代码时重点看四个分支：client.Do 返回错误时不要访问空响应体；成功后是否立即安排关闭；状态码异常是否提前返回；重试循环每一轮是否都有独立的 Body 生命周期。把关闭动作放在获得响应后的第一时间，能显著减少遗漏。

用连接池参数限制空闲资源

当请求访问很多主机，或者并发量有明显峰值时，连接池参数决定了“请求结束后还保留多少资源”。MaxIdleConns 控制所有主机的空闲连接总数，MaxIdleConnsPerHost 控制单个主机的空闲连接数，IdleConnTimeout 控制空闲连接最多保留多久。它们处理的是连接复用策略，不是响应体关闭的替代品。

transport := &http.Transport{
    // 跨所有目标主机限制空闲连接总量，避免访问主机过多时池子无界增长。
    MaxIdleConns: 100,
    // 为热点主机保留适量连接，具体值按并发和上游容量压测调整。
    MaxIdleConnsPerHost: 10,
    // 空闲超过该时长后主动关闭，避免长期保留不再使用的 keep-alive 连接。
    IdleConnTimeout: 90 * time.Second,
    // 只有需要限制拨号、活动和空闲连接总量时才设置它。
    MaxConnsPerHost: 50,
}
client := &http.Client{Transport: transport}

不要看到连接多就直接设置 DisableKeepAlives: true。这会牺牲复用能力，可能增加握手和延迟；更稳妥的顺序是先修复 Body 生命周期，再根据主机数量、并发量和空闲时长调整池参数。

在生命周期结束时关闭空闲连接

长期运行的共享客户端一般让 Transport 自己管理连接池；临时客户端、上游切换或优雅退出时，则可以主动关闭已经空闲的连接。CloseIdleConnections 的语义是清理“当前没有请求使用”的连接，它不会打断正在进行的请求。

func shutdownClient(client *http.Client, transport *http.Transport) {
    // Client 方法会把关闭请求转交给底层 Transport；两者按一个生命周期调用即可。
    client.CloseIdleConnections()

    // 如果代码持有 Transport 本身，也可以直接调用它的同名方法；不要重复放入业务热路径。
    transport.CloseIdleConnections()
}

上面的示例展示了两个等价入口，实际项目应选择一个，避免重复表达。更重要的是不要把它放到每个请求结束处：请求结束后立刻关闭全部空闲连接，会让连接池失去复用价值。

用指标和代码审查确认修复

修复后不要只看某一时刻的连接数。应该按同一流量窗口观察请求完成数、响应体关闭路径、活动连接、空闲连接和文件描述符趋势。连接数在请求高峰后逐步回落，且长期稳定在配置上限附近，通常比“必须归零”更符合连接池的设计。

代码审查可以按这张清单走：

• 每个 err == nil 的响应是否都安排了 Body.Close。
• 早返回、重试、超时和状态码分支是否共享同一关闭路径。
• Transport 是否被复用，而不是在循环或每次请求中重新创建。
• 自定义 DialContext、代理和 TLS 配置是否有明确的取消与退出路径。
• CloseIdleConnections 是否只放在客户端生命周期结束、配置切换或优雅退出阶段。

常见问题

为什么调用了 CloseIdleConnections，连接数仍然不为零？

它只关闭空闲连接，不会终止活动请求、正在拨号的连接，也不会替代响应体关闭。先确认请求是否已经结束，再看连接是否处于 idle 状态。

每次请求都 new 一个 Transport 能解决资源问题吗？

通常会让问题更复杂。每个 Transport 都可能维护自己的连接池，短时间内创建很多实例会削弱复用并增加连接数量。应让一个 Transport 覆盖明确的客户端生命周期，并在生命周期结束时清理空闲连接。

只关闭 Body 不设置 IdleConnTimeout 可以吗？

可以解决最常见的响应体遗漏，但空闲连接仍可能按池策略保留。是否需要设置超时取决于访问主机数量、流量峰谷和上游连接策略，不能用一个固定值替代压测和观测。