Go 自动解压后读取内容为空的 Header 处理

我排查 Go HTTP 客户端时，最容易误判的一类问题是：响应明明有数据，代码却在解压之后读到空内容，或者一检查 Content-Encoding 就发现它不见了。这个现象通常不是服务端返回了空 Body，而是 http.Transport 已经替你处理了 gzip，或者同一个 Body 被前面的代码读完了。

这篇只讨论三个对象：Transport 的压缩策略、Content-Encoding Header，以及 Response.Body 的读取边界。官方资料地址：https://pkg.go.dev/net/http。

先看 resp.Uncompressed，再决定是否创建 gzip.Reader；默认 Transport 自己请求 gzip 时，Response.Body 通常已经是解压后的内容。读取为空时，还要确认 Body 没有被前一次 io.ReadAll 消耗。

我第一次误判：Header 消失不代表内容消失

默认 Transport 在请求没有显式设置 Accept-Encoding、且没有关闭压缩时，可能自动添加 Accept-Encoding: gzip。如果服务端返回 gzip，Transport 会把响应体透明解压后交给调用方。此时 resp.Uncompressed 为 true，Content-Encoding 和 Content-Length 可能已经从响应 Header 中移除，Body 直接提供明文。

所以这段判断很容易把正确的自动解压路径当成异常：

encoding := resp.Header.Get("Content-Encoding")
// 中文说明：自动解压后这个字段可能为空，不能只凭它决定是否解压。
if encoding == "gzip" {
    // 中文说明：这里再套一层 gzip.Reader，可能把已经解压的明文当成 gzip 字节。
}

真正要区分的是两条 Body 路径

我现在会先把请求方式分成两种。第一种是让 Transport 自己协商 gzip：代码不设置 Accept-Encoding，直接读取 resp.Body。第二种是代码显式写入 Accept-Encoding: gzip，这表示调用方接管压缩协议，不能再假设 Transport 会自动解压，读取时要根据 Header 手动创建解压读取器。

默认路径可以保持很简单：

resp, err := http.DefaultClient.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close() // 中文说明：无论读取是否成功，都要释放响应体资源。

data, err := io.ReadAll(resp.Body)
if err != nil {
    return err // 中文说明：读取错误不能被空切片掩盖。
}
fmt.Printf("uncompressed=%v bytes=%d\n", resp.Uncompressed, len(data))
// 中文说明：默认自动解压路径直接消费 Body，不再套 gzip.Reader。

如果业务必须自己控制压缩字节，例如要保留原始 gzip 内容，就要明确关闭 Transport 的自动行为，并把解压责任放在同一段代码里：

transport := &http.Transport{
    DisableCompression: true, // 中文说明：不让 Transport 自行请求并透明解压 gzip。
}
client := &http.Client{Transport: transport}

resp, err := client.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close() // 中文说明：原始响应 Body 仍由响应对象负责关闭。

reader := io.Reader(resp.Body)
if resp.Header.Get("Content-Encoding") == "gzip" {
    gz, err := gzip.NewReader(resp.Body)
    if err != nil {
        return err // 中文说明：Header 声称 gzip 但字节不合法时要立即返回。
    }
    defer gz.Close() // 中文说明：gzip.Reader 也有自己的读取状态，需要关闭。
    reader = gz
}

data, err := io.ReadAll(reader)
if err != nil {
    return err // 中文说明：统一从最终 reader 读取，避免同一 Body 被读两次。
}
return use(data)

读取为空时，我会按这三个点排查

第一，确认是否重复读取。io.ReadAll(resp.Body) 会把流读到末尾，第二次读取自然得到空字节。需要把结果保存下来传给后续逻辑，而不是再次从 Body 读取。

第二，确认是否重复解压。默认 Transport 已将 Body 变成明文时，继续调用 gzip.NewReader(resp.Body) 就把错误边界放错了。判断自动解压时优先看 resp.Uncompressed，不要只看已经被 Transport 改写过的 Header。

第三，确认显式 Header 的责任归属。如果请求代码主动设置了 Accept-Encoding: gzip，就要把它和手动的 gzip.NewReader 放在同一个设计里；如果只是想普通读取响应，不要为了“省流量”自行加 Header 后又沿用默认 Transport 的读取假设。

我的结论：先选责任边界，再写读取代码

对我来说，最稳妥的习惯是把“谁负责解压”和“谁负责关闭”写在同一个读取函数里。只要先确定 Transport 已经把 Body 变成哪一层，再处理 Header，所谓“自动解压后读取为空”的问题通常就能落到一个明确的重复读取或重复解压点上。

相关问题

为什么 Content-Encoding 为空但 Body 还有内容？

因为默认 Transport 可能已经透明解压，并删除表示原始压缩格式的 Header；Body 提供的是解压后的内容。

能不能总是手动调用 gzip.NewReader？

不能。只有拿到仍然是 gzip 字节的 Body 时才应该手动解压，否则会把明文流当作压缩流处理。

为什么第一次读取有内容，第二次读取为空？

Response.Body 是流，读取到末尾后不会自动回到开头。需要缓存第一次读取结果，或在确有必要时重新发起请求。