响应体未关闭导致连接池耗尽怎么办

Go HTTP 客户端在 client.Do 返回成功后，必须负责关闭 resp.Body。修复响应体遗漏时，应把每次请求的读取和 Close 放进一个会及时返回的函数，让成功、状态码异常和读取失败路径都能收尾。若希望 HTTP/1.x 长连接具备复用条件，还要关注正文是否读到 EOF；但不要为了复用而无限读取未知大小或持续不断的响应。

官方地址：https://pkg.go.dev/net/http#Client.Do

一直等连接，是不是已经耗尽连接池？

响应体未关闭可能让连接资源长时间被占用，出现连接数增加、文件描述符压力、请求排队或超时。不过 Go Transport 不是所有情况下都有一个固定大小的连接池。设置 MaxConnsPerHost 后，单个目标的连接达到上限，新请求可能等待；没有这个上限时，也可能先表现为连接持续增长。

我会先区分“等待可用连接”和“等待服务器响应”，再查看响应体的所有权：哪个函数得到 Body，哪个函数保证关闭，异常分支是否提前返回。这里的判断顺序是排障建议，不是宣称出现连接超时就一定属于泄漏。

Close 和 EOF 分别解决什么？

Close 是调用方结束使用响应体的动作。读到 EOF 则表示这份正文已经完整读完，两者不应混为一谈。尤其 HTTP/1.x 连接需要明确当前响应消息的结束，才可能承接后续请求。读完不等于可以省略 Close，只 Close 也不应理解为所有情况下都必然复用。

当前官方文档还说明，Transport 在关闭 Body 后会尝试在保守限额内异步读取剩余正文。这属于实现提供的便利，不是调用方可以依赖的无限排空保证。对于需兼容不同工具链或自定义 RoundTripper 的代码，明确关闭和控制读取规模仍然更可靠。这里不把“手工 drain 所有响应”设为统一要求。

怎样让每次请求都及时收尾？

以下函数面向小体积 GET 响应，最多接受 1 MiB 正文。它多读取一个字节来判断是否超限，所有已成功取得响应体的路径都通过 defer 关闭。调用方应复用配置好超时的 Client，目标地址来自业务可信配置。本例使用 errors.Join，要求 Go 1.20 或更高版本。

package fetch

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

const maxBody = 1  maxBody {
        return nil, errors.New("响应体超过 1 MiB")
    }
    if resp.StatusCode = 300 {
        // 不把远端错误正文直接拼进日志，避免泄漏业务数据。
        return nil, fmt.Errorf("远端状态码: %d", resp.StatusCode)
    }
    return data, nil
}

对于小于等于限额且正常结束的响应，读取会触及真实 EOF。超限时主动停止继续读取并关闭，优先保证本地读取规模受限，不承诺该连接仍然复用。读取错误时返回 nil 数据；若 Close 也失败，错误会合并返回。调用方应始终先判断 err，再使用 data。

这个实现会为非 2xx 响应读取有上限的正文，然后返回状态码错误，适合预期错误体较小的接口。若业务不需要错误体，可以选择直接关闭，但要接受连接复用可能受影响。Client.Do 不会仅因为 404 或 500 就返回非 nil 错误，因此状态检查不能省略。

循环与重试中，defer 放哪里？

如果在一个持续运行的大循环里不断执行 defer resp.Body.Close，关闭动作要等整个外层函数返回才发生，并不是每轮结束就执行。GetSmall 将作用域缩小到一次请求，因此即使循环很多次，每次调用返回前也完成对应收尾。

// client 在循环外建立并复用，超时值按接口服务目标调整。
client := &http.Client{Timeout: 8 * time.Second}
for _, endpoint := range endpoints {
    data, err := fetch.GetSmall(ctx, client, endpoint)
    if err != nil {
        // 真实项目在这里分类错误；重试前上一份 Body 已完成关闭。
        log.Printf("请求失败: %v", err)
        continue
    }
    consume(data)
}

这段是调用位置示意，fetch 为上面包的实际导入名，ctx、endpoints、consume 由业务提供，time、http、log 需按实际代码导入。示例没有启动服务或执行网络请求，也没有编造连接数恢复数据。重试仍要另外考虑次数、退避、幂等性和总时间预算。

大文件、流式响应和连接配置怎么选？

大文件应分块写到目标存储并限制总规模，不适合直接 ReadAll。流式响应则可能长时间没有 EOF，消费结束或取消时关闭 Body，并让请求上下文及适当的超时策略负责退出。小响应函数中的固定总超时，不应原样套用到需要长连接的事件流。

MaxIdleConnsPerHost 管理的是空闲连接保留数量，不能修复仍被占用的 Body。MaxConnsPerHost 管理每个目标的连接总量，也不能替代 Close。CloseIdleConnections 只关闭当前空闲连接，不会中断正在使用的连接，所以它不是清理所有未关闭响应体的办法。

HTTP/2 可以在连接上复用多个流，不能直接套用“一份响应体独占一条 TCP 连接”的解释，但及时关闭不再需要的 Body 仍然必要。定位时应记录实际协议、并发量、响应大小、超时类别和调用作用域，依据现场信息判断资源在哪里滞留。

只取状态码也要关闭吗？

要。Do 成功后会提供非 nil Body，即使应用不读取正文，也应结束对它的使用。

把连接池开大能暂时解决吗？

它可能延后症状，也会增加资源消耗。应先修复每次请求的关闭路径，再依据正常并发需求配置连接数量。

为什么修复 Close 后还是超时？

还可能有 DNS、建连、响应头、正文读取或服务端延迟等原因。不能把所有超时都归到响应体遗漏，应结合错误类别继续定位。

官方参考：https://pkg.go.dev/net/http#Client.Do；连接配置：https://pkg.go.dev/net/http#Transport。