Go HTTP 请求发送后为什么忘记关闭 Body

Go HTTP客户端不会因为Do返回了响应、读到了EOF或状态码异常，就免除调用者关闭 resp.Body 的责任。常见遗漏是把“请求发送成功”当成整个请求处理结束，或在检查状态码时提前return。正确写法是在 err == nil 后立即安排Close，并让读取与关闭尽量位于同一个短函数中。

官方地址：https://go.dev/

我倾向于让请求辅助函数直接返回读完的数据，这样调用处不必猜谁负责关闭。只有大文件下载或流式消费才把Body交给上层，同时明确转交关闭责任。这里分享的是代码组织方式，不虚构连接数下降等运行经历。

拿到响应就确定关闭责任

先区分Request.Body与Response.Body。标准Transport负责关闭客户端发出的请求体；成功取得的响应体则由调用者关闭。不能因为两者都叫Body，就认为请求发出后所有Body都已自动收尾。

非2xx状态不会自动让Client.Do返回错误；所以不能只在“请求成功且状态200”分支关闭。若Do返回错误，按标准Client契约可直接处理错误，不应在尚未确认resp有效前就defer resp.Body.Close。

用短函数收拢读取与关闭

最小配方是“先检查Do错误，再登记响应体关闭，再检查状态和读取”。完整代码放在后文，关键点是关闭动作覆盖后续所有返回路径，读取错误也不会绕过释放。

普通小响应可以读成字节切片返回，从函数接口上消除流的所有权歧义。需要保留Close错误时，用命名返回值在defer里合并，不能直接忽略先前读取错误。不要为了报告关闭错误而覆盖真正导致请求失败的原因。

Client应复用，Body按单次响应关闭。每个请求都新建Client并不能替代资源管理，还会让连接复用策略难以维护。CloseIdleConnections只处理空闲连接，也不能作为遗漏Body.Close的通用补丁。

区分读到EOF和释放资源

读到EOF说明数据读取结束，Close表示调用者不再使用这个流。二者不同。HTTP/1.x持久连接是否可复用，受读体完成、关闭、连接状态及服务端策略等条件影响；Close也不等同于每次都关闭底层TCP连接。

当前标准库文档说明，Transport在关闭响应体时可能尝试做有限度的异步读取收尾；不应依赖这个实现细节来假定任何大小响应都会被读完。对于已经读完的小响应，仍要Close；对于很大或不需要的响应，应优先及时关闭并保持明确的超时与字节限制。

不要为了复用连接无条件io.Copy到io.Discard。面对持续输出或异常大的响应，无上限排空会消耗时间与带宽。限制读取后提前关闭，可能牺牲该连接的复用，但能遵守应用的资源预算。

循环与流式接口分别处理

循环里defer不会在本次迭代结束时执行，而是等包含循环的函数返回。如果循环持续处理大量URL，全部响应体都留到最后关闭，资源会被不必要地持有。把一次请求放进readPage这类函数，每次返回便完成关闭，通常比在多个分支手工Close更清楚。

流式接口则应返回io.ReadCloser或明确的响应对象，并在文档说明由调用者关闭。辅助函数返回流时，不要在内部defer关闭它；也不要提前cancel该流仍需要的Context。读流、关闭和取消应由能够覆盖整个消费过程的上层范围负责。

同一个Body通常按单一消费者设计，不能把它当作可重复读取的数据副本。需要多个消费者时，可以在大小限制内读成字节数据，再为各自创建独立Reader。

用完整片段固定团队写法

以下程序需要Go 1.20或更新版本，以使用errors.Join。它只访问参数指定的测试服务，不启动服务，不添加自动重试。

package main

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

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

func readPage(ctx context.Context, url string) (data []byte, retErr error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return nil, fmt.Errorf("创建请求: %w", err)
    }
    resp, err := client.Do(req)
    if err != nil {
        return nil, fmt.Errorf("发送请求: %w", err)
    }
    // 获取响应成功便登记关闭，状态码异常也会执行。
    defer func() {
        if err := resp.Body.Close(); err != nil {
            retErr = errors.Join(retErr, fmt.Errorf("关闭响应体: %w", err))
        }
    }()
    if resp.StatusCode != http.StatusOK {
        return nil, fmt.Errorf("响应状态: %s", resp.Status)
    }
    const limit = 512  limit {
        return nil, fmt.Errorf("响应体超过 %d 字节", limit)
    }
    return data, nil
}

func main() {
    if len(os.Args) != 2 {
        fmt.Fprintln(os.Stderr, "请提供测试服务地址")
        return
    }
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel() // 请求及读取结束后释放上下文资源。
    data, err := readPage(ctx, os.Args[1])
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
    fmt.Printf("读取完成，字节数=%d\n", len(data))
}

# 先准备自己控制的测试服务，再传入对应地址。
go run main.go "http://127.0.0.1:8080/page"

预期正常小响应会打印字节数；状态异常、读取失败、超限与关闭失败会返回相应错误。无论是否200，成功取得的响应体都会经过defer关闭。这些是代码预期，本文未声称已执行本地请求。

io.ReadAll成功后还要Close吗？

要。读取完成不替代关闭责任，两个动作都应在接口设计中有明确位置。

只看状态码，不要正文，也要Close吗？

要。在Do成功取得响应后，哪怕马上根据状态码返回，也应安排关闭。

Body.Close会关闭整个Client吗？

不会。它结束当前响应体的使用，Client本身可以继续复用。底层连接的后续处置由Transport和协议状态决定。

把责任写进函数边界，比依赖调用者记忆更稳妥：小响应在函数内读完并关闭，流式响应把关闭责任明确交给实际消费者。

官方资料：Client.Do与响应体契约；Response.Body说明。