本文详解 Go 的 net/http 客户端行为：未读取响应体时不会自动丢弃数据，必须显式关闭 Response.Body；Content-Length 不可靠，需结合 io.LimitReader 和资源清理策略实现安全、低开销的响应预检。
本文详解 go 的 `net/http` 客户端行为：未读取响应体时不会自动丢弃数据，必须显式关闭 `response.body`；`content-length` 不可靠，需结合 `io.limitreader` 和资源清理策略实现安全、低开销的响应预检。
在 Go 中使用 http.Client.Do() 发起请求后，HTTP 响应体并不会因你未调用 ioutil.ReadAll()（或 io.ReadAll()）而被自动跳过或丢弃。相反，如果应用未主动读取或关闭 response.Body，底层 TCP 连接将保持打开状态，客户端可能无法复用连接，更严重的是——服务端持续发送的响应数据仍会经网络传输并堆积在缓冲区中，造成隐性流量浪费和内存泄漏风险。
自 Go 1.12 起（commit ce83415），net/http 客户端在检测到 response.Body 未被读取且未被关闭时，会主动关闭底层网络连接（而非静默读空剩余字节）。这意味着：
✅ 避免了“偷偷吃掉全部响应体”的隐蔽开销；
⚠️ 但同时也意味着：若你仅检查 Header 就放弃读取，却忘记 Close()，不仅连接无法复用，还可能触发服务端重试或超时异常。
因此，正确策略不是依赖 HEAD 请求，而是“按需预读 + 显式关闭”：
✅ 推荐做法：使用 io.LimitReader 安全预检
req, err := http.NewRequest("GET", url, nil)
if err != nil {
return err
}
resp, err := httpClient.Do(req)
if err != nil {
return err
}
defer resp.Body.Close() // 始终确保关闭！
// 检查 Content-Type
contentType := resp.Header.Get("Content-Type")
if !strings.HasPrefix(contentType, "application/json") {
return fmt.Errorf("unexpected content type: %s", contentType)
}
// 获取 Content-Length（注意：可能为空）
contentLength := resp.ContentLength
const maxBodySize = 1 << 20 // 1MB 阈值
var body []byte
if contentLength != -1 && contentLength <= maxBodySize {
// 已知长度且在阈值内 → 安全读取全部
body, err = io.ReadAll(resp.Body)
} else {
// 长度未知或超限 → 仅读取最多 maxBodySize 字节
limited := io.LimitReader(resp.Body, maxBodySize)
body, err = io.ReadAll(limited)
if err == nil && len(body) == maxBodySize {
// 实际响应更大 → 可选择丢弃或报错
return fmt.Errorf("response exceeds size limit (%d bytes)", maxBodySize)
}
}
if err != nil {
return err
}
// 此时 body 已按需加载，后续可解析或处理⚠️ 关键注意事项：
- resp.Body.Close() 必须调用：即使你完全不读取 Body，也应在检查 Header 后立即 Close()，否则连接泄漏、goroutine 阻塞风险极高；
- Content-Length 并非强制字段：HTTP/1.1 允许分块传输编码（chunked encoding）或流式响应，此时该 Header 为空，resp.ContentLength 为 -1；
- HEAD 请求不可靠：虽然 HEAD 不含响应体，但 RFC 并不要求服务端在 HEAD 响应中返回 Content-Length；实践中许多 CDN 或代理会省略该头，无法作为预判依据；
- 不要重复请求：用一次 GET + LimitReader 预检，比 HEAD + GET 更高效、更符合 HTTP 语义。
✅ 最佳实践总结：
- 总是 defer resp.Body.Close()（或在 error 分支显式关闭）；
- 优先基于 Content-Type 和业务逻辑决策是否继续读取；
- 使用 io.LimitReader 控制最大读取量，而非依赖 Content-Length；
- 对超限响应明确拒绝，避免内存爆炸；
- 避免 HEAD + GET 的两轮往返，除非服务端明确保证 HEAD 返回完整元信息。
这样既保障了网络资源效率，又维持了代码健壮性与可维护性。
