Go http.Response.Body读取后不关闭导致连接复用异常的排查方法

Go 的 HTTP 请求返回成功后，resp.Body 不是“用不用都无所谓”的字段。只要 err == nil，调用方就应该负责关闭它；如果希望底层 Transport 复用 keep-alive 连接，正常路径还要把响应体读到 EOF。只写 defer resp.Body.Close() 能避免资源长期悬挂，但不能替代读取未消费的响应体。

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

最稳妥的判断是：成功响应先安排 Close，再根据业务是否需要完整内容决定读完；提前返回时，若还希望 HTTP/1.x 连接复用，就先消费剩余 Body，否则应接受这次连接可能不能复用。

读取结束与 Body.Close 的调用关系

一个最小且容易复用的写法如下。defer 放在确认 resp 不为空之后，避免在请求失败时解引用空响应；io.Copy 则把“我不需要正文”与“我没有读正文”区分开。

client := &http.Client{Timeout: 5 * time.Second}
resp, err := client.Get("https://api.example.com/health")
if err != nil {
    return err
}
// 只有拿到有效响应后才能安排关闭，避免错误路径访问空指针。
defer func() {
    // 关闭响应体，释放本次响应占用的读取资源。
    _ = resp.Body.Close()
}()

// 业务不需要正文，也要消费到 EOF，给 Transport 留下复用连接的机会。
if _, err := io.Copy(io.Discard, resp.Body); err != nil {
    return err
}
if resp.StatusCode = 300 {
    // 状态码仍需由业务判断；非 2xx 不等于 Do 返回 error。
    return fmt.Errorf("unexpected status: %s", resp.Status)
}
return nil

这里的两个动作职责不同：读到 EOF 让 Transport 知道响应内容已消费完，Close 则明确结束 Body 生命周期。即使某些实现会在关闭时尝试有限度地继续读取，也不要把它当成“可以永远不读”的保证。

用现象区分未关闭与未读完

排查时先看所有返回路径，而不是只搜索一处 Close。常见现象可以按下面的方向分开：

尤其注意：HTTP 状态码为 404 或 500 时，Do 通常仍会返回一个非空 Response 和 nil error。只检查 err，很容易在状态异常分支中直接返回，顺手漏掉 Body 生命周期。

提前返回时的连接复用排查清单

业务常常只想读取响应头，或者遇到状态码后不再解析正文。这时可以把“是否值得读完”写成明确的策略，而不是让每个调用点自由发挥。

func checkResponse(resp *http.Response) error {
    // 调用方必须传入成功获得的响应，并对 Body 负责。
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        // 小响应可以直接读完，尽量保留 keep-alive 复用机会。
        _, _ = io.Copy(io.Discard, resp.Body)
        return fmt.Errorf("remote status: %s", resp.Status)
    }

    // 只读取本例需要的少量内容；读取失败仍由调用方记录。
    var result HealthResult
    if err := json.NewDecoder(resp.Body).Decode(&result); err != nil {
        return fmt.Errorf("decode health response: %w", err)
    }
    return nil
}

如果错误响应可能很大，或者正文来自持续流式接口，就不要为了复用而无界读取。此时应明确记录“本次连接不保证复用”，并检查上游协议是否提供更合适的健康检查或摘要接口。关键是让这个取舍出现在代码和监控里，而不是靠偶然行为。

复用 Client 与 Transport 的工程边界

http.Client 可以并发使用，底层 Transport 会维护连接缓存。把 Client 放在服务对象或进程级依赖中，通常比每次请求创建一个新 Client 更容易获得连接复用。不要为了“清理”每个请求都调用 CloseIdleConnections；它适合发布配置、下线或明确的连接回收场景，不是普通请求的收尾动作。

上线前可做三项核对：所有 nil error 的响应是否都有 Close；需要复用的短响应是否读到 EOF；Client 是否在循环外创建。再结合客户端请求耗时、服务端新建连接数和 Transport 的空闲连接变化观察修复效果，就能把“连接复用异常”从猜测变成可定位的生命周期问题。

常见追问

只调用 Close，不读完 Body，可以吗？ 可以结束生命周期，但不能保证持久连接复用。若后续请求量大且响应体小，优先读到 EOF 再关闭。

非 2xx 是否一定进入 error 分支？ 不一定。HTTP 状态码属于响应内容，网络传输成功时 err 仍可能为 nil，必须单独判断 StatusCode。