Go HTTP 响应体忘记关闭：连接占用与 Goroutine 增长的排查修复

一台 Go API 服务上线后，订单同步接口的平均耗时没出现明显上涨，Goroutine 数量却从几百条慢慢涨到了几千条。最开始团队把排查方向放在上游网络侧，后来在调用方的异常分支里找到了一个很小但影响深远的遗漏：拿到 *http.Response 后，状态码不对就直接返回，resp.Body 没做关闭处理。对 net/http 来说，响应体不是用完就能随便丢的临时对象，它直接决定底层 TCP 连接能不能被正常回收复用。

告警出现时，先拆分清楚影响范围

这类问题通常不像内存泄漏那样直接把监控曲线拉成直线。如果是一个低频率轮询任务，每秒只是多遗留一点未关闭的响应体，流量低的时候几乎没感知；等到并发量上涨、上游网络开始抖动，服务端的连接池很快就会被占满，请求开始排队，Goroutine 持续增长的曲线才会凸显出来。

复盘的时候可以先把能看到的所有症状整理出来，别着急直接调大连接池上限。连接数突然上涨不等于根因一定在网络层，盲目扩容 Transport 的阈值，也只是把问题爆发的时间往后推一点而已。

顺着时间线定位到非成功响应分支

这里用一个简化的订单同步场景还原整个排查过程：同步服务按固定频率请求 /v1/settlement，上游偶尔会返回 429 限流或者 502 错误。上线后前十分钟所有业务指标都正常，运行大约半小时后，连接数和 Goroutine 同步抬升，之后开始出现更多调用超时报错。

1. 先用 curl /debug/pprof/goroutine?debug=1 拉取聚合调用栈，确认增长的 Goroutine 基本都阻塞在 net/http 的连接读写路径附近。
2. 再把状态码按接口维度拆分统计，发现上游返回异常时 Goroutine 涨速明显变快，成功响应占绝大多数的时候曲线反而很平稳。
3. 最后沿着所有 return 分支走查调用封装逻辑，发现异常状态码的分支完全没有处理 resp.Body。

这时候不用急着把问题归罪到 HTTP/2 或者某个反向代理身上。协议类型、上游是否主动断开连接、响应体大小都会影响现场表现，但 Go 标准库的基础约束从来没变：调用方拿到响应体用完之后，必须主动执行关闭。官方 net/http 文档也把 defer resp.Body.Close() 放在客户端示例代码的紧邻位置。

触发点不在成功路径，而在提前返回的错误逻辑

下面这段代码是非常常见的写法：请求成功就直接解码 JSON，状态码不对就直接返回错误信息。问题出在 return 之前，完全没有释放已经拿到的响应体资源。

func loadSettlement(ctx context.Context, client *http.Client, endpoint string) (Settlement, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
    if err != nil {
        return Settlement{}, err
    }

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

    if resp.StatusCode != http.StatusOK {
        return Settlement{}, fmt.Errorf("upstream status: %s", resp.Status)
    }

    var item Settlement
    if err := json.NewDecoder(resp.Body).Decode(&item); err != nil {
        return Settlement{}, err
    }
    return item, nil
}

这种写法在本地单次调试的时候根本看不出问题，因为程序很快就退出了，操作系统会自动回收所有打开的资源。放到长期运行的服务里，每一次异常响应都可能把一条 TCP 连接的生命周期拖得很长，重试一多，问题症状就会被快速放大。更麻烦的是，这类错误分支的压测覆盖率通常远低于成功路径，很容易被漏过去。

根因修复：关闭响应体，同时让错误响应在有边界的前提下读完

修复的核心思路不是“遇到错误才想起关”，而是拿到响应对象的第一时间，就用 defer 注册关闭动作。之后再根据状态码决定后续读取逻辑：成功路径交给 JSON 解码器自动消费全量内容，错误路径只读取一小段上游返回内容留作日志排查，关闭前尽量把剩余内容读完。这里的 4 只是示例上限，实际使用的时候可以按照错误体的常规大小和日志存储策略调整。

func loadSettlement(ctx context.Context, client *http.Client, endpoint string) (Settlement, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
    if err != nil {
        return Settlement{}, err
    }

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

    if resp.StatusCode != http.StatusOK {
        sample, _ := io.ReadAll(io.LimitReader(resp.Body, 4

限量读取和读完剩余内容看起来有点繁琐，两者的作用完全不同：前者是限制写入日志的内容长度，避免无意义的日志膨胀，后者是让客户端有机会把响应内容消费完毕，让出连接复用资格。不要直接把上游返回的整页 HTML 错误内容全塞到日志里，不然会给日志系统带来额外的负载压力。如果是大文件下载、流式传输这类不需要复用连接的特殊场景，可以按照对应接口的协议规范单独设计读取策略。

修复完成后还要校验 Client 和 Transport 的边界配置

关闭响应体解决的是资源释放的责任问题，但 http.Client 的创建方式直接决定连接池有没有机会正常工作。如果为每一个请求都新建一个独立的 http.Client，会直接绕过连接复用逻辑，连接的运行状态也会更难观测。通常更稳妥的做法是服务启动阶段创建一个全局共享的客户端，统一配置超时和空闲连接相关策略。

transport := &http.Transport{
    MaxIdleConns:        100,
    MaxIdleConnsPerHost: 20,
    IdleConnTimeout:     90 * time.Second,
    ResponseHeaderTimeout: 3 * time.Second,
}

client := &http.Client{
    Transport: transport,
    Timeout:   8 * time.Second,
}

这些配置参数没有适配所有场景的通用标准答案。上游域名数量、并发峰值、响应体大小和失败重试策略都会影响最合适的阈值。生产环境建议先把空闲连接数这类参数设得偏保守一点，通过压测和灰度发布阶段观测连接复用率、请求耗时分位数和端口使用情况，再逐步调整，不要一次性把所有阈值都拉到最大。

把修复逻辑转化为可落地的测试和告警规则

实用的回归测试不需要强行校验 Goroutine 的绝对数值。可以用 httptest.NewServer 模拟成功和失败两类响应，循环调用对应的 HTTP 封装函数，再比对调用前后的 Goroutine 增量是否在合理范围内，阈值要提前留出测试环境本身的波动空间。

before := runtime.NumGoroutine()
for i := 0; i  before+20 {
    t.Fatalf("goroutine grew too much: before=%d after=%d", before, after)
}

线上监控可以把四类指标放到同一个大盘里展示：请求调用总量与各状态码占比、客户端超时次数、活跃 TCP 连接数或文件描述符数量、Goroutine 总数。几类指标同步出现异常的时候，排查路径会短很多。针对团队内部的 HTTP 调用封装逻辑，还可以加一条代码审查规则：代码里只要出现 client.Do，就必须在同一个函数里找到明确对应的 resp.Body.Close() 调用。

常见问题

只调用 Close 方法，不读完响应体内容也可以吗？

可以完成资源释放，但连接能不能直接被复用，会受响应是否被消费到末尾、传输协议版本和 Transport 当前状态的影响。处理常规小体积 JSON 或者错误响应时，读完再关闭更容易保持稳定的连接复用率；大流量流式接口要按照业务自身的边界规则处理。

所有 http.Client 都可以跨 Goroutine 共享使用吗？

Go 标准库文档明确说明 Client 和 Transport 本身支持多个 Goroutine 并发安全使用，正常场景下创建一次之后全局复用就可以。前提是不要在请求运行过程中随意修改共享 Client 的配置参数。

Goroutine 持续增长一定是响应体没关闭导致的吗？

不一定。阻塞 channel、未取消的 context、重试风暴、数据库连接等待都可能产出类似的持续增长曲线。把 pprof 调用栈、接口状态码分布和连接类指标结合起来一起分析，才不容易出现误判。

遇到非 200 状态码的时候为什么还要读取一部分响应内容？

短小的错误片段能帮你快速定位上游实际返回的异常原因，配合长度上限还能避免日志内容过度膨胀。读取内容用于问题诊断，执行关闭用于释放系统资源，两个动作都不能省略。

收尾：让每一次 HTTP 调用的资源都能明确回收

这次排查真正值得沉淀下来的不是某个 Transport 配置参数，而是调用外部 HTTP 服务的固定习惯：构造请求的时候带上 context，拿到响应立刻注册关闭逻辑，成功和失败所有分支都处理响应体，全局复用同一个 Client 实例，再通过压测观测连接数量和 Goroutine 增长的关联关系。资源释放的逻辑写在离资源获取最近的地方，线上服务才不容易留下这类慢慢发酵的隐性问题。