Go HTTP 响应里的 gzip 压缩头为什么不见了

用 Go 的 http.Client 请求接口时，抓包明明能看到 Content-Encoding: gzip，代码里却读不到这个响应头，resp.Body 反而可以直接交给 JSON 解码器。这通常不是服务端漏发，而是 http.Transport 在替调用方做透明解压。

默认情况下，如果请求没有自己设置 Accept-Encoding、没有 Range、方法也不是 HEAD，Transport 会添加 Accept-Encoding: gzip。当服务端返回 gzip 时，Go 会把解压后的内容放进 Response.Body，并删除 Content-Encoding、Content-Length，同时将 Response.Uncompressed 设为 true。

一、gzip 头消失是响应被转换了吗

可以把链路分成两层：服务器在线路上返回压缩字节，Transport 再把它包装成解压读取器。调用方拿到的 resp 已经是第二层结果，所以不要用“响应头是否还在”推断服务器有没有压缩。

如果 resp.Uncompressed 为 true，这是最直接的判断信号。此时 ContentLength 也可能变成 -1，因为解压后的长度不再等于线路上的压缩长度。

二、先检查哪些请求会触发自动解压

排查时先看请求代码，而不是马上给 Body 套 gzip.NewReader。Transport 只在以下条件同时满足时自行添加 gzip：DisableCompression 为 false、请求没有 Accept-Encoding、没有 Range，并且方法不是 HEAD。

三、用 Body 和 Uncompressed 做一次可复查的验证

下面的示例只读取解压后的数据，不再重复解压。注释说明了判断点；生产代码还应根据接口大小增加读取上限。

package main

import (
	"encoding/json"
	"fmt"
	"net/http"
)

type payload struct {
	Name string `json:"name"`
}

func main() {
	resp, err := http.Get("https://example.com/data.json")
	if err != nil {
		panic(err)
	}
	defer resp.Body.Close() // 无论是否压缩，都要释放响应体

	fmt.Println("status:", resp.Status)
	fmt.Println("uncompressed:", resp.Uncompressed)

	var data payload
	if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
		panic(err) // Body 已可直接按 JSON 读取时，不要再次套 gzip.Reader
	}
	fmt.Println("name:", data.Name)
}

这里的 resp.Header.Get("Content-Encoding") 为空并不矛盾：它描述的是当前返回对象保留的编码元数据，而不是抓包时服务器在线路上曾经使用的编码。需要诊断原始报文时，应在请求前明确关闭 Transport 的自动压缩。

四、需要原始压缩字节时明确关闭自动压缩

如果要把 gzip 字节保存到文件、计算压缩包校验值，或交给另一个解压组件，就不要让 Transport 先替你解压。最小配置如下：

transport := &http.Transport{
	DisableCompression: true, // 不由 Transport 自动添加 Accept-Encoding: gzip
}
client := &http.Client{Transport: transport}

req, err := http.NewRequest(http.MethodGet, "https://example.com/data.json", nil)
if err != nil {
	panic(err)
}
resp, err := client.Do(req)
if err != nil {
	panic(err)
}
defer resp.Body.Close() // 保存或手动解压前也必须关闭

fmt.Println("encoding:", resp.Header.Get("Content-Encoding"))
// 这里读取到的是否为 gzip，仍以服务端实际返回的响应头为准。

DisableCompression 只表示 Transport 不主动请求 gzip，并不保证任意服务端都返回未压缩数据。若请求代码显式写了 Accept-Encoding: gzip，Go 文档明确说明不会自动替你解压；此时必须由业务代码承担解压、错误处理和资源关闭。

相关问题

为什么 Content-Length 也不见了？

Transport 解压后删除了压缩响应的长度字段，并把内容长度设为未知，调用方应通过读取 Body 判断结束。

能不能只通过 Content-Encoding 判断是否解压？

不建议。优先看 Response.Uncompressed，再结合请求是否由 Transport 自动添加 gzip 判断。

显式设置 Accept-Encoding 后怎么处理 Body？

按响应头决定是否创建 gzip.NewReader，并同时关闭原始 Body 与解压读取器，避免重复解压。

这类问题的关键不是“把消失的请求头找回来”，而是先确认当前 Response.Body 处在哪一层：默认 GET 可能已经是明文；原始字节需求则应在 Transport 配置和请求头上提前声明。