Go 问答：HTTP 响应体不关闭为什么连接越来越多？

Go 调外部 HTTP 接口时，有一种问题很隐蔽：业务日志没有明显报错，但运行一段时间后连接数越来越多，接口偶发变慢，甚至出现端口耗尽或连接池等待。排查到最后，常常发现原因只是一个细节：resp.Body 没有被正确读完并关闭。

这篇按问答和调试清单的方式说明：为什么响应体必须处理，怎么分层检查，看到哪些证据可以判断是这类问题，以及修复后如何反向验证连接复用已经恢复。

现象：请求成功了，连接却越来越多

先看一个常见的错误写法。函数只关心状态码，不读取响应体，也没有关闭响应体：

package main

import (
    "fmt"
    "net/http"
)

func pingRemote(url string) error {
    resp, err := http.Get(url)
    if err != nil {
        return err
    }

    if resp.StatusCode >= 400 {
        return fmt.Errorf("remote status: %s", resp.Status)
    }
    return nil
}

这段代码在功能测试里可能“能跑”，因为接口确实返回了状态码。但对 net/http 客户端来说，响应体是一个需要调用方负责释放的资源。如果不处理它，底层连接不能稳定回到可复用状态，长时间运行后就容易出现连接数量异常。

问题更容易出现在这些地方：

• 只判断状态码，不需要响应内容的探活接口。
• 错误分支提前返回，忘了关闭响应体。
• 循环里频繁请求第三方接口，但没有统一封装资源释放。
• 读取 JSON 时中途出错，直接返回错误，没有处理剩余响应体。

分层检查：先看代码，再看连接和日志

这类问题不要只盯着连接数。推荐按三层看：代码是否有释放路径，连接池是否复用，日志是否能对应到某个调用点。

第一层：代码里是否有关闭路径

搜索所有 client.Do、http.Get、http.Post 调用，看拿到 resp 后是否有 defer resp.Body.Close()，并且错误状态码分支也能走到关闭。

rg "http\\.Get|http\\.Post|client\\.Do|\\.Do\\(" .

如果某个函数里有多个提前返回，重点检查这些返回之前是否已经安排关闭。

第二层：连接数是否随流量回落

本地或测试环境可以观察连接状态。不同系统命令略有差异，核心是看同一个远端地址的连接数是否持续上涨。

ss -tan | grep ':443' | awk '{print $1}' | sort | uniq -c

如果请求停止后连接数仍长时间不回落，或者同一个目标地址连接数量明显超过预期，就要回到代码里检查响应体处理。

第三层：日志里是否能定位调用点

建议在外部调用封装里记录目标服务、状态码、耗时和错误。不要让每个业务函数都直接散写 HTTP 请求，否则排查时很难知道是哪条路径没有释放资源。

证据判断：哪些信号指向 Body 没处理

下面这些证据放在一起看，基本可以把问题范围缩小到响应体处理。

这里要注意一个细节：关闭响应体是必须动作；如果还希望 HTTP/1.x 连接尽量复用，通常还需要把响应体读到结束。Go 官方文档也提醒过，默认传输层在响应体没有读完并关闭时，可能无法复用底层连接。

修复动作：读完、关闭、错误路径也要处理

如果需要解析响应体，最简单的写法是拿到 resp 后立刻安排关闭，然后正常读取：

func fetchJSON(client *http.Client, url string) error {
    resp, err := client.Get(url)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    if resp.StatusCode >= 400 {
        return fmt.Errorf("remote status: %s", resp.Status)
    }

    // 这里可以用 json.NewDecoder(resp.Body).Decode(&out)
    return nil
}

如果不关心响应内容，比如只做探活或只需要状态码，建议显式丢弃读取，再关闭：

package main

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

var client = &http.Client{
    Timeout: 3 * time.Second,
}

func checkStatus(url string) error {
    resp, err := client.Get(url)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    _, _ = io.Copy(io.Discard, resp.Body)

    if resp.StatusCode >= 400 {
        return fmt.Errorf("remote status: %s", resp.Status)
    }
    return nil
}

如果担心超大响应体，不要无限制丢弃读取。可以在业务层限制响应大小，或者只对受控接口使用这类写法。核心原则是：资源释放要明确，响应大小要可控。

反向验证：连接数是否回落并稳定

修复后要做一次反向验证。不要只看单次请求成功，而要看连续请求后的连接状态。

1. 用压测或循环请求打到同一个测试接口，例如连续请求 1000 次。
2. 观察同一个远端地址的连接数是否稳定在合理范围。
3. 停止请求后，连接数是否按预期回落。
4. 日志里没有大量临时连接、读响应失败或超时堆积。

可以写一个小循环做本地验证：

func main() {
    for i := 0; i 

如果修复有效，连接数量不会随着循环次数线性上涨。更理想的状态是：请求期间连接池保持在一个稳定范围，请求停止后按空闲连接策略回落。

排查清单：下次直接按这几项看

• 拿到 resp 后是否总能调用 resp.Body.Close()。
• 错误状态码分支是否也能处理响应体。
• 不需要响应内容时，是否显式丢弃读取再关闭。
• 是否复用同一个 http.Client，而不是每次请求新建。
• 是否给客户端或请求设置超时，避免读取阶段无限等待。
• 是否有目标服务、状态码、耗时和错误日志，方便定位调用点。

总结一下，Go HTTP 客户端的响应体不是可有可无的对象。只要 resp 不为空，调用方就要负责处理 resp.Body。读完并关闭，连接才有机会被稳定复用；错误分支和不关心内容的分支也不能例外。把这件事封装成团队统一的 HTTP 调用模板，能少掉很多连接数异常和偶发慢请求。