如何在 Go 中处理 HTTP 客户端的连接泄露问题

先说说你很可能遇到过的场景：线上服务跑着跑着，突然冒出 socket: too many open files，而且几乎没法短时间恢复——因为新请求连socket都创建不了。

这种"慢性死亡"式的故障，十次里有八九次都指向同一个问题：Go HTTP客户端连接泄漏。而泄漏的根因，往往不是单点失误，而是三个坏习惯叠加的结果。

为什么 resp.Body.Close() 必须显式调用

Go的http.Client默认开启了连接复用（Keep-Alive），但复用的前提是：响应体必须被完整读取并关闭。如果只调用http.Get或client.Do，拿到resp后不做任何处理，底层TCP连接就无法归还给连接池——它会一直挂在readLoop的goroutine里等待数据，即便服务端早已发完所有内容。

常见的错误表象有三个：

• 系统日志里反复出现 too many open files
• 用 lsof -i :443 | wc -l 一查，连接数只涨不降
• 通过 pprof 看 /debug/pprof/goroutine?debug=1，大量goroutine卡在net.(*pollDesc).Wait或persistConn.readLoop

正确的做法不是“偶尔记得defer”，而是每次成功拿到resp后，立即安排关闭：

resp, err := client.Get("https://api.example.com")
if err != nil {
    return err
}
defer resp.Body.Close() // ✅ 放在 err 检查之后、任何读取之前

需要注意：defer在函数退出时才执行。如果这个函数生命周期很长（比如后台worker循环），应该改用显式的resp.Body.Close()，避免堆积。

Transport 配置不当如何加剧连接堆积

即使你每次都关了resp.Body，如果http.Transport参数没调好，连接依然可能卡在idle状态不释放，或者新建了过多连接、无法复用。

几个关键配置项值得认真对待：

• MaxIdleConns / MaxIdleConnsPerHost：默认值是100，高并发场景下很容易成为瓶颈。建议设置为500甚至更高，具体数值要与后端实例数量匹配。
• IdleConnTimeout：空闲连接存活时间。设太长（比如90秒），连接占着文件描述符不放；设太短（比如5秒），又会导致频繁建连。推荐30秒作为折中。
• TLSHandshakeTimeout / ResponseHeaderTimeout：这两个超时尤其重要——防止TLS握手卡死，或者服务端迟迟不发header导致连接永久悬挂。

典型错误写法是直接用 &http.Client{} 而不配置 Transport，或者复用 http.DefaultClient，却被第三方库悄悄修改了它的 Transport 参数。

安全的初始化方式如下：

client := &http.Client{
    Timeout: 30 * time.Second,
    Transport: &http.Transport{
        MaxIdleConns:        500,
        MaxIdleConnsPerHost: 500,
        IdleConnTimeout:     30 * time.Second,
        TLSHandshakeTimeout: 10 * time.Second,
        ResponseHeaderTimeout: 10 * time.Second,
    },
}

403 等非 2xx 响应体也必须消费

很多人只在StatusCode == 200时读取resp.Body，却忽略了403、401、500等响应里也可能携带非空body——可能是HTML错误页、JSON提示信息，或者Content-Length: 345之类的头部。只要body没被读完或没被关闭，连接就不会释放。

更危险的是重试逻辑：如果对403直接重试，而不处理上一次的resp.Body，等于每轮都泄漏一个连接。

可靠的做法是：无论状态码如何，都确保body被消费并关闭：

resp, err := client.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close()

// 即使不需要内容，也要把 body 读完，否则连接无法复用
_, _ = io.Copy(io.Discard, resp.Body)

这行io.Copy(io.Discard, resp.Body)很关键——它显式消费流，让http.Transport知道可以回收连接了。

全局复用 client 实例而非每次 new

最隐蔽的泄漏源之一是：在HTTP handler或循环中反复创建新的http.Client实例。每个client都自带独立的Transport和连接池，新建即新增资源占用，旧的还可能因未关闭而滞留。

错误模式是这样的：

func handler(w http.ResponseWriter, r *http.Request) {
    client := &http.Client{} // ❌ 每次请求都 new，连接池各自为政
    resp, _ := client.Get("https://...")
}

正确的做法是定义包级或全局变量来复用：

var httpClient = &http.Client{
    Timeout: 30 * time.Second,
    Transport: &http.Transport{ /* 如上配置 */ },
}

func handler(w http.ResponseWriter, r *http.Request) {
    resp, _ := httpClient.Get("https://...") // ✅ 复用同一实例
}

如果业务需要不同超时策略（比如上传任务vs 普通查询），可以按用途分组定义多个client变量，但不要按请求动态构造。

基于线上排查的经验来看，连接泄漏之所以难以根除，就是因为它不是单点失误——往往是Body未关、Client未复用、Transport未调优这三件事同时发生。而一旦线上触发了too many open files，恢复窗口极短，因为新请求连socket都建不起来。所以，提前把这三件事管好，远比事后应急更稳妥。