在 Go 中，若调用 http.Client.Do() 后未显式关闭 resp.Body，将造成文件描述符泄漏和 TCP 连接无法复用，进而影响性能与稳定性；正确做法是先检查错误再 defer resp.Body.Close()。
在 go 中，若调用 `http.client.do()` 后未显式关闭 `resp.body`，将造成文件描述符泄漏和 tcp 连接无法复用，进而影响性能与稳定性；正确做法是先检查错误再 `defer resp.body.close()`。
在 Go 的 HTTP 客户端编程中，resp.Body 是一个实现了 io.ReadCloser 接口的流式响应体。它底层持有一个网络连接（通常是持久化的 TCP 连接），必须被显式关闭——这不仅是释放内存的需要，更是释放操作系统级资源（如文件描述符）和维持连接池健康的关键操作。
为什么不能忽略 resp.Body.Close()？
- ❌ 连接无法复用：net/http.Transport 默认启用 keep-alive。若 Body 未读取完毕或未关闭，该 TCP 连接将被标记为“不可复用”，长期闲置后超时断开，但期间无法用于后续请求，导致新建连接增多；
- ❌ 文件描述符泄漏：每个未关闭的 Body 对应一个打开的 socket 文件描述符。在高并发场景下，大量泄漏会迅速耗尽系统 ulimit 限制（如 Too many open files 错误）；
- ❌ 内存持续占用：虽然 Go 垃圾回收器最终会回收 Body 对象，但底层 OS 资源（如 socket、缓冲区）不会被自动释放，因此属于典型的 resource leak（资源泄漏），而非单纯的内存泄漏。
正确的关闭时机与写法
关键原则：必须在确认 err == nil 且 resp != nil 后，再调用 Close()。因为：
- 当 client.Do() 返回非 nil 错误时（如网络超时、DNS 失败），resp 可能为 nil；
- 即使 err == nil，resp.Body 也保证非 nil（官方文档明确承诺），因此可安全调用 Close()。
✅ 推荐写法（顺序严格）：
client := http.DefaultClient
resp, err := client.Do(req)
if err != nil {
return nil, fmt.Errorf("HTTP request failed: %w", err)
}
defer resp.Body.Close() // 此时 resp 和 resp.Body 均确定非 nil
// 读取响应体（建议读到 EOF，例如使用 io.ReadAll 或 resp.Body.Close() 前完整消费）
body, err := io.ReadAll(resp.Body)
if err != nil {
return nil, fmt.Errorf("failed to read response body: %w", err)
}
// 处理 body...
⚠️ 错误示例（危险！可能导致 panic）：
resp, err := client.Do(req)
defer resp.Body.Close() // ❌ 若 err != nil，resp 可能为 nil → panic: nil pointer dereference
if err != nil {
return nil, err
}
额外建议：确保 Body 被完全消费
除 Close() 外，Transport 还期望 Body 被读取至 EOF（例如通过 io.ReadAll, json.NewDecoder(resp.Body).Decode() 等），否则仍可能阻碍连接复用。若无需全部内容，可用 io.Copy(io.Discard, resp.Body) 显式丢弃剩余数据：
defer func() {
io.Copy(io.Discard, resp.Body) // 确保读完
resp.Body.Close()
}()
或者更简洁地结合 io.ReadAll（它内部已隐含 EOF 判断）：
body, _ := io.ReadAll(resp.Body) // 即使忽略 err，也完成了读取 defer resp.Body.Close()
总结
- resp.Body.Close() 不是可选项，而是 HTTP 客户端资源管理的强制义务；
- 关闭前务必校验 err，避免对 nil 指针操作；
- defer 是优雅方式，但必须置于 if err != nil 检查之后；
- 实践中，应始终配合完整读取（或显式丢弃）响应体，以最大化连接复用效率。
遵循以上规范，可显著提升 Go HTTP 客户端的稳定性、性能与可观测性。
