Go HTTP 客户端请求后连接为什么没有复用

Go HTTP 客户端连续请求却没有复用连接，首先检查响应体是否被正确处理，以及请求是否共享同一个 Transport。对于 HTTP/1.x，读到真实 EOF 并关闭 Body 是常见的复用前提，但不是连接必然复用的保证；上游主动关闭、请求取消、空闲超时和连接池配置也会让下一次请求重新建连。

官方文档入口：https://pkg.go.dev/net/http。本文给出有限响应体的原创封装和 httptrace 观测入口，不是已经运行的连接实验，也不把一次请求延迟降低当成复用证据。

连接复用减少的是重复建连成本

连接复用的意义是减少连续请求中的重复 TCP 建连以及可能的 TLS 握手成本。客户端与 Transport 都可以并发使用，适合在组件初始化后长期共享。真正缓存连接的是 Transport；每次都创建新的 Transport，就把请求放进彼此独立的池里。

反过来，单纯创建新的 http.Client 并不总是隔离连接池：Transport 为 nil 的 Client 使用默认 Transport。排障时要确认底层对象的身份，而不是只数 Client 构造次数。CloseIdleConnections 也不是每个请求的清理函数，频繁调用会主动清理可用于后续请求的空闲连接。

先区分 HTTP/1.x 与 HTTP/2 的响应体责任

Do 返回 nil 错误后，调用者负责关闭非 nil 的响应 Body，即使响应没有内容或状态码不是 2xx。只解析一个 JSON 对象，也不能自动证明底层响应体已经到 EOF；剩余空白、额外内容或更大的响应仍可能未读完。

HTTP/1.x 的消息边界与单连接顺序复用相关。当前官方文档也说明，Transport 在关闭 Body 后可能在保守上限内异步尝试读完剩余内容，因此不能写成“只 Close 永远不能复用”。实际行为与所用 Go 工具链和剩余数据有关，不应依赖内部阈值。显式读完小响应仍让资源边界更清楚。

HTTP/2 使用流复用，不能照搬 HTTP/1.x 的空闲连接推理。它仍要求关闭 Body，以释放流相关资源；一个未关闭的响应不等于整条 TCP 连接必然不能承载其他请求。排障先记录 resp.Proto，再解释观测结果。

“请求组件”分组包含 Client、Transport 与连接池；“响应资源”分组包含 Body、真实 EOF 与 Close。Client 与 Transport 是使用关系，Transport 与连接池是管理关系；Body 与真实 EOF、Close 是读取完成及资源关闭责任，响应资源与 Transport 的关系说明协议层能否继续使用连接。

共享 Transport 并在函数内读完关闭

先将 Client 初始化放到请求循环之外，再把一次响应处理放在单独函数里。下例限定最多 1 MiB，读取 maxBody+1 字节用于识别超限。没有超限且读取成功时，底层响应读完；超过限制时及时关闭并返回错误，不为连接复用无限读取不可信内容。

package upstream

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

// NewClient 只在组件初始化时调用，之后共享同一个连接池。
func NewClient() *http.Client {
    tr := http.DefaultTransport.(*http.Transport).Clone()
    return &http.Client{Transport: tr, Timeout: 8 * time.Second}
}

// FetchSmall 适用于有限大小的普通响应，不用于长连接流。
func FetchSmall(ctx context.Context, client *http.Client, url string) ([]byte, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return nil, err
    }
    resp, err := client.Do(req)
    if err != nil {
        return nil, err
    }
    // 每次调用函数返回即关闭，不把 defer 累积在大循环里。
    defer resp.Body.Close()
    const maxBody = 1  maxBody {
        return nil, fmt.Errorf("响应体超过 %d 字节", maxBody)
    }
    // 错误状态也已经走过读取与关闭路径。
    if resp.StatusCode = 300 {
        return nil, fmt.Errorf("上游状态码：%d", resp.StatusCode)
    }
    return data, nil
}

调用者在初始化时保存 NewClient 返回值，连续调用 FetchSmall 共享它。Clone 默认 Transport 是为了保留标准配置基础，再按业务需要调整；不要在 FetchSmall 内 Clone，也不要在请求进行时任意修改共享 Transport 字段。8 秒超时和 1 MiB 上限都是示例策略，应结合上游响应大小与时延预算调整。

defer 写在 FetchSmall 内部，函数每次返回就执行关闭。如果直接在一个长循环里对每次响应 defer，关闭会推迟到外层函数结束，连续请求期间仍会积累资源。错误状态也必须经过清理；不要看到 500 就直接返回而遗漏 Body.Close。

限流读取器达到上限时产生的 EOF 不一定是原始响应 EOF。示例多读一字节并判断超限，正是避免把人为截断当成读完。读取错误、超限和取消路径允许放弃某次连接复用；这比无边界地排空响应更符合请求资源预算。

用 httptrace 观察而不是凭延迟猜测

在请求上下文中附加 httptrace，使用 GotConn 的 Reused 观察本次拿到的连接是否用过。WasIdle 表示来自空闲状态，不是所有复用协议都必须为 true。PutIdleConn 用于观察空闲回池情况，但官方文档明确它目前不用于 HTTP/2，不能因没有该回调就认定 HTTP/2 没复用。

package upstream

import (
    "context"
    "log"
    "net/http/httptrace"
)

// TraceContext 为请求附加连接观测，不记录响应体或鉴权头。
func TraceContext(ctx context.Context) context.Context {
    hooks := &httptrace.ClientTrace{
        GotConn: func(info httptrace.GotConnInfo) {
            // 回调可能并发发生，使用日志器而非修改共享 map。
            log.Printf("连接复用=%t 空闲=%t", info.Reused, info.WasIdle)
        },
        PutIdleConn: func(err error) {
            // 此钩子不能当作 HTTP/2 的通用回池证明。
            log.Printf("回池结果=%v", err)
        },
    }
    return httptrace.WithClientTrace(ctx, hooks)
}

可以把 TraceContext(ctx) 传给 FetchSmall，按相同目标、相同共享 Client、顺序请求且完整处理响应的条件采集日志。首次请求通常需要建立连接，后续是否复用仍取决于协议、服务端和池状态。重定向可能触发多个连接事件；应关联请求标识和目标，而不是把一行日志解释为全局复用率。

“连接观测”分组包含 GotConn、Reused 和 WasIdle；“协议上下文”分组包含 resp.Proto、PutIdleConn 和 HTTP/2。GotConn 与两个字段是数据组成关系，resp.Proto 与 HTTP/2 是协议识别关系，PutIdleConn 与 HTTP/2 表示钩子适用限制。这里画的是观测契约，不是虚构连接轨迹。

大响应、取消与服务端关闭的取舍

不要对任意响应无条件 io.Copy(io.Discard, Body)。大下载、慢速上游、持续流或不可信内容可能消耗大量带宽和时间。小而有限的响应可读完；大响应或流式场景应按业务协议处理，提前退出时关闭或取消，接受资源回收与复用机会之间的取舍。

DisableKeepAlives、请求的 Close、服务端关闭指示、MaxIdleConnsPerHost 与 IdleConnTimeout 影响连接行为，但增加池容量不会修复 Body 泄漏。MaxIdleConnsPerHost 管的是每个目标可保留的空闲连接，不是一个让所有并发请求共用一条 TCP 连接的开关。

Close 成功是否保证复用？不保证。它完成调用者清理责任；传输和协议还要判断连接是否可用。

客户端超时只管收到响应头吗？Client.Timeout 包含建连、重定向和响应体读取。不要为了排空 Body 绕过原请求期限。

为什么关闭 Body 后仍有连接？空闲连接可能被池保留，这是正常复用机制；要结合活跃请求、trace 和超时判断，而不是把所有开放连接都当泄漏。

排查顺序可以概括为：先确认共享 Transport 和实际协议，再检查所有响应路径是否读取与关闭，最后观察上游关闭、取消及空闲池策略。连接复用是条件允许时的传输优化，不是调用一次 Close 后必然成立的承诺。

技术事实依据：https://pkg.go.dev/net/http；追踪钩子与字段：https://pkg.go.dev/net/http/httptrace。示例为原创，未执行实测，不包含真实账号、响应内容或鉴权日志。