HTTP响应体少读一个字节导致连接不复用怎么办

Go HTTP 客户端出现连接数持续增长、连接复用率下降时，问题不一定是 Transport 配错了。一个很隐蔽的原因是：JSON 解码器读完了对象，却没有把响应体读到 EOF。例如服务端返回 {"ok":true}\n，解码器消费完右花括号后，末尾换行仍然留在响应体里。对 HTTP/1.x 来说，这一个字节也意味着当前响应还没有完整结束，连接就可能无法回到 keep-alive 空闲池。

官方资料：https://pkg.go.dev/net/http

修复的核心不是盲目新建 Client，而是在关闭响应体前确认是否还需要消费剩余内容：小响应直接读完；只关心状态码时按上限排空；剩余内容过大或过慢时接受这条连接不复用。

一个换行为什么会影响连接复用

http.Client.Do 返回的 Response.Body 是流式读取器。JSON 解码器的目标是得到一个完整 JSON 值，不是替调用方读取响应流的全部字节。因此，下面这种写法在响应末尾带换行时，可能在逻辑上已经拿到对象，但在传输层还没有看到 EOF：

resp, err := http.Get(endpoint)
if err != nil {
    return err
}
defer resp.Body.Close() // 只负责释放资源，不等于业务上已经读到 EOF

var result struct {
    OK bool `json:"ok"`
}
// JSON 解码可能在右花括号处结束，末尾换行仍留在 Body 中。
if err := json.NewDecoder(resp.Body).Decode(&result); err != nil {
    return err
}
return nil

这不是每次都会表现为错误。下一次请求可能只是重新建立 TCP 连接，功能照样成功，但握手、TLS 协商和连接建立成本会反复发生。Go 官方文档也把“读到 EOF 并关闭”作为 HTTP/1 keep-alive 复用的前提；Go 官方连接复用文章则用“JSON 后多一个换行”说明了这个边界。

先判断你面对的是 HTTP/1 还是 HTTP/2

这个问题最直接影响 HTTP/1.x。HTTP/1 的多个请求响应在同一条连接上按顺序排列，前一个响应的尾部没有读完，Transport 就不能安全地把这条连接交给下一个请求。HTTP/2 使用独立流复用一条连接，某个流的未读响应体不会以同样的方式阻塞其他流，但调用方仍然必须关闭 Body，避免资源泄漏和流长期占用。

排查时不要只看 resp.StatusCode 是否正确，还要检查响应体处理方式、Transport 的空闲连接数量和服务端是否返回了无用正文。把 DisableKeepAlives 设为 true 只能绕开复用，不能修复响应体生命周期；而且它会让每个请求都失去连接复用收益。

小响应直接读完，再关闭 Body

如果接口响应本身很小，最清晰的做法是先把正文读入内存，再解析。这样解析器面对的是字节切片，不会把“解析结束”和“网络流结束”混在一起：

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

    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close() // 读取完成后仍要关闭响应体

    // ReadAll 会消费包括末尾换行在内的全部正文，避免留下尾字节。
    raw, err := io.ReadAll(resp.Body)
    if err != nil {
        return err
    }

    var result struct {
        OK bool `json:"ok"`
    }
    // Unmarshal 只负责解析已经读完的字节，不再参与网络流读取。
    if err := json.Unmarshal(raw, &result); err != nil {
        return err
    }
    if !result.OK {
        return errors.New("remote response is not ok")
    }
    return nil
}

这个方案适合有明确大小上限的 JSON、配置或状态响应。生产代码应当结合业务设置响应体上限，避免把不受控的大正文全部读进内存。

只需要 JSON 字段时，解码后显式排空

如果响应体可能较大，但业务只想拿几个字段，可以保留流式解码，同时在解码成功后把剩余内容复制到丢弃端：

func decodeAndDrain(resp *http.Response, dst any) error {
    defer resp.Body.Close() // 无论解析成功与否，都释放 Body

    // Decoder 可能在 JSON 值结束处返回，不能因此假设已经到 EOF。
    if err := json.NewDecoder(resp.Body).Decode(dst); err != nil {
        return err
    }

    // 消费 JSON 后的换行、空白或其他已知尾部，让 HTTP/1 响应到达 EOF。
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return err
    }
    return nil
}

这里的 io.Copy 是关键动作。它不是为了再次解析 JSON，而是为了继续消费响应流。若排空过程中遇到网络错误，就不要把这条连接复用当成已经成立的事实。

响应体很大时不要无限排空

排空正文也有代价。如果服务端返回几十 MB 的无用内容，或者响应以很慢的速度到达，为了复用旧连接而一直等待，可能比重新建连接更慢。可以给排空设置字节预算；超过预算就关闭 Body，并接受当前 HTTP/1 连接不再复用：

func drainLimitedAndClose(body io.ReadCloser) error {
    // 只为复用连接最多丢弃 256 KiB，避免无界等待或无界读取。
    _, drainErr := io.CopyN(io.Discard, body, 256

Go 的 Transport 在关闭响应体后也会尝试在保守的字节数和时间范围内排空，但应用代码不应把这个内部策略当作无限制保证。是否手动排空，取决于正文大小、响应速度以及建立新连接的成本。

用这张清单选择实现

最后再检查两点：不要为每次请求创建新的 http.Client；不要用关闭 keep-alive 来掩盖 Body 没有正确消费的问题。真正需要的是让响应体的生命周期与连接复用策略匹配。

相关问题

只调用 resp.Body.Close 不够吗？

它始终是必须动作，但不能把 Close 等同于“应用已经读完响应”。对 HTTP/1 连接复用，最稳妥的约定仍是读到 EOF 后关闭；当正文过大时，则应明确接受不复用。

为什么 json.Decoder 会留下换行？

Decoder 以 JSON 值结束作为本次 Decode 的完成点，JSON 值之后的空白可能仍由底层 Reader 提供。它没有义务为了连接池继续读取整个 HTTP 响应。

能不能直接把 DisableKeepAlives 打开？

可以作为临时隔离手段，但它牺牲了连接复用，不能替代正确关闭响应体。修复 Body 消费逻辑后，应根据实际协议和响应大小重新启用复用。