Go http.Response.Uncompressed 怎样判断响应是否自动解压

Go 客户端拿到响应后，如果发现 Body 的内容已经不是服务器发送的压缩字节，先看 resp.Uncompressed。它为 true 时，说明是 net/http.Transport 自己协商并完成了透明解压；这不等于服务器返回了未压缩内容。

官方文档：https://pkg.go.dev/net/http#Response.Uncompressed

这个字段最容易在排障时被忽略：解压后的 Body 可以正常读取，但 Content-Length 会变成 -1，响应头里的 Content-Encoding 和 Content-Length 也会被移除。下面按最小判断路径拆开。

为什么 Response.Uncompressed 会变成 true

默认 Transport 会在请求没有显式设置 Accept-Encoding 时，代替调用方请求 gzip。如果服务器返回 gzip 响应，Transport 会把解压后的内容放进 Response.Body，同时把 Uncompressed 标记为 true。

这解释了一个常见症状：抓包看到响应压缩了，程序却能直接把 Body 当 JSON 或文本读取。压缩发生在网络表示层，应用读取的是 Transport 处理后的表示。

先看三个字段，不要只看 Content-Encoding

排查时建议把三个信号放在一起看：

因此，Content-Encoding 为空不能单独证明服务器没有压缩；如果 Uncompressed 为 true，应把它理解为“压缩响应已经在 Transport 内部被解码”。

用最小代码记录判断结果

把判断放在读取 Body 之前，能避免读取动作改变排障上下文。下面只展示字段关系和资源关闭方式：

package main

import (
    "fmt"
    "io"
    "net/http"
)

func inspect(url string) error {
    // 使用默认 Transport，让它按规则决定是否自动请求并解压 gzip。
    resp, err := http.Get(url)
    if err != nil {
        return err
    }
    // 响应体由调用方负责关闭，避免连接无法回收或复用。
    defer resp.Body.Close()

    // 先记录解压标记和响应头，再读取正文，便于定位字段变化。
    fmt.Printf("uncompressed=%v contentLength=%d encoding=%q\n",
        resp.Uncompressed,
        resp.ContentLength,
        resp.Header.Get("Content-Encoding"),
    )
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return err
    }
    // 此处的 body 是应用实际读到的内容；自动解压时它不是 gzip 字节流。
    fmt.Printf("body-bytes=%d\n", len(body))
    return nil
}

如果只需要判断是否透明解压，核心判断就是 if resp.Uncompressed { ... }。不要用“响应头是否仍有 gzip”替代它，也不要把 ContentLength 当成解压后正文的准确长度。

想保留原始压缩响应怎么办

当日志采样、签名校验或自定义解码需要原始字节时，应在 Transport 上设置 DisableCompression: true。它会阻止 Transport 在请求未显式指定编码时自动添加 gzip 协商，也就不会替你透明解压。

package main

import (
    "io"
    "net/http"
)

func readOriginal(url string) ([]byte, error) {
    transport := &http.Transport{
        // 禁止 Transport 自动请求和解压 gzip，保留服务器响应的原始表示。
        DisableCompression: true,
    }
    client := &http.Client{Transport: transport}
    resp, err := client.Get(url)
    if err != nil {
        return nil, err
    }
    // 读取完成后关闭响应体，保持连接资源生命周期清晰。
    defer resp.Body.Close()
    return io.ReadAll(resp.Body)
}

另一种容易混淆的情况是：调用方自己设置了 Accept-Encoding: gzip。此时请求头不是 Transport 自动添加的，Transport 不会按同一条自动解压路径处理，调用方需要自己负责解码和错误处理。

排障时的选择表

一句话总结：Response.Uncompressed 判断的是“Go 的 http 包是否完成了透明解压”，不是“服务器有没有压缩”。需要原始响应时关闭 Transport 的自动压缩处理，需要业务正文时则优先消费解压后的 Body，并始终关闭响应体。

相关问题

为什么 ContentLength 变成 -1？

因为原始长度对应的是压缩表示，解压后长度不能再沿用该值，标准库会把它设为未知值。

为什么 Content-Encoding 为空但 Uncompressed 为 true？

这是 Transport 对响应表示做过透明处理后的正常结果，判断是否解压应以 Uncompressed 为主。

关闭 DisableCompression 后还能自动处理 gzip 吗？

不能指望 Transport 再自动完成这一步。保留原始字节后，应由业务代码按实际编码和协议自行解码。