Go Transport.DisableCompression 开启后为什么请求头行为会变化

我第一次排查 Go HTTP 客户端的压缩响应时，最容易误判的一点是：看到 Transport.DisableCompression 就以为它会“禁止所有 gzip”。实际上它只控制 Transport 是否自动补充 Accept-Encoding: gzip，而响应是否自动解压，还取决于这个 gzip 请求头是不是由 Transport 自己添加的。

直接结论：没有显式设置 Accept-Encoding 时，DisableCompression=false 允许 Transport 自动请求 gzip，并在收到 gzip 响应后透明解压；设置为 true 后不再自动请求。若调用方自己写了 Accept-Encoding: gzip，则即使 DisableCompression=false，响应也不会由 Transport 自动解压，读取方要自己处理压缩 Body。

官方资料：https://pkg.go.dev/net/http#Transport.DisableCompression

这篇只讨论请求头、透明解压和响应字段的关系，不展开服务端到底使用哪一种压缩算法。把三条责任边界分开后，调试日志里的“请求头变了”和“Body 读出来不一样”就容易解释了。

先区分自动请求头和显式请求头

DisableCompression 的判断点是“Request 里有没有现成的 Accept-Encoding”。请求没有这个字段时，Transport 才有机会根据配置自动加上 Accept-Encoding: gzip；请求已经带了这个字段时，Transport 不会把调用方的意图改写成自己的透明解压路径。

下面的最小配置可以表达“不要让 Transport 自动请求 gzip”，但它不会替调用方删除显式请求头。也就是说，DisableCompression=true 和“强制把所有请求的 Accept-Encoding 清空”不是一回事。

package main

import (
	"fmt"
	"net/http"
)

func newRawResponseClient() *http.Client {
	// true 只关闭 Transport 自动添加 Accept-Encoding: gzip 的路径。
	transport := &http.Transport{DisableCompression: true}
	return &http.Client{Transport: transport}
}

func main() {
	client := newRawResponseClient()
	request, err := http.NewRequest(http.MethodGet, "https://example.com/data", nil)
	if err != nil {
		// 构造请求失败时直接返回，避免拿无效请求继续发送。
		panic(err)
	}

	response, err := client.Do(request)
	if err != nil {
		// 网络错误需要由业务决定重试、降级或记录。
		panic(err)
	}
	defer response.Body.Close() // 读取完成后释放连接相关资源。

	fmt.Println(response.Header.Get("Content-Encoding"))
}

理解自动 gzip 路径的响应变化

当 Transport 自己请求 gzip 并收到 gzip 响应时，http.Response 暴露给业务的不是服务器原始压缩流，而是透明解压后的 Body。此时可以观察到几个配套变化：Uncompressed 为 true，Content-Encoding 和 Content-Length 会从响应头语义中移除，ContentLength 设为 -1。

这些变化不是服务端“没有返回压缩”，而是 Transport 已经在客户端内部完成了处理。若日志要记录服务器原始响应，就不能只看解压后的 Body；要保留原始压缩内容，应关闭自动协商并自行决定如何读取。

读取 Body 的代码本身不需要因为透明解压而改成特殊 API；真正要改变的是你对响应元数据的解释。下面的记录函数把“是否由 Transport 透明解压”和“响应头是否仍声明编码”分开打印，避免把两个概念混成一个布尔值。

func logCompressionState(response *http.Response) {
	// Uncompressed=true 表示 Transport 自己请求 gzip 后完成了透明解压。
	fmt.Printf("transparent=%t content-encoding=%q content-length=%d\\n",
		response.Uncompressed,
		response.Header.Get("Content-Encoding"),
		response.ContentLength,
	)
}

如果是透明解压路径，response.Body 可以直接交给 JSON 解码器或文本读取器。不要再基于 Content-Encoding: gzip 重复包一层 gzip Reader，因为该字段已经被 Transport 的自动解压逻辑处理过。

按业务约束选择三种 Transport 配置

从工程角度看，这不是一个“哪个值永远正确”的开关，而是三个负载和约束不同的决策。我的经验是先问清楚：业务要的是方便读取、原始响应，还是完全掌控压缩格式。

普通客户端可以把 Transport 当作共享基础设施复用，但不要在同一个 Transport 生命周期里随意切换用途。负责透明解压的客户端和负责保留原始压缩响应的客户端，最好通过清晰的构造函数分开表达，日志和故障定位会更稳定。

func newClientForManualGzip() *http.Client {
	transport := &http.Transport{
		DisableCompression: true, // 关闭自动 gzip 协商，交给调用方决定请求头。
	}
	return &http.Client{Transport: transport}
}

func addExplicitEncoding(request *http.Request) {
	// 显式请求 gzip 后，响应 Body 是否压缩由调用方负责确认和处理。
	request.Header.Set("Accept-Encoding", "gzip")
}

这里的关键不是把 DisableCompression 和显式请求头机械地同时使用，而是明确“谁拥有压缩协议的所有权”。如果调用方显式请求了 gzip，就应同时设计好对 Content-Encoding 的处理、压缩流错误和 Body 关闭顺序。

处理显式请求头与读取边界

最常见的故障是：代码手动设置了 Accept-Encoding: gzip，随后又把 response.Body 当作普通 JSON 直接解码。此时 Transport 不会因为看到 gzip 就替你解压，读取到的可能仍是压缩字节，JSON 解码自然会失败。

手动路径至少要先看响应头，再决定是否创建 gzip Reader。下面示例只展示责任边界；实际业务还应根据状态码、最大读取量和解压炸弹防护补充限制。

func readResponseBody(response *http.Response) ([]byte, error) {
	defer response.Body.Close() // 无论后续是否创建解压 Reader，都只关闭原始 Body。

	reader := io.Reader(response.Body)
	if strings.EqualFold(response.Header.Get("Content-Encoding"), "gzip") {
		gzipReader, err := gzip.NewReader(response.Body)
		if err != nil {
			// 压缩头损坏时不要继续把压缩字节交给上层解析器。
			return nil, err
		}
		defer gzipReader.Close() // 释放 gzip Reader 的内部状态。
		reader = gzipReader
	}

	return io.ReadAll(reader)
}

这段代码依赖 compress/gzip、io 和 strings 包；注释中的“原始 Body”指 Transport 返回的响应体对象，不等于一定是服务器原始字节，是否透明解压仍要结合 Transport 配置和 Response.Uncompressed 判断。

形成一份可落地的排障清单

遇到“同一个接口有时返回压缩、有时返回明文”时，我会按下面的顺序记录，而不是先改服务端配置：

1. 先看请求：请求创建后是否已经有 Accept-Encoding，以及它是业务代码设置的还是由 Transport 自动补的。
2. 再看配置：确认实际使用的 http.Client.Transport 是否为自定义 Transport，DisableCompression 的值是否符合当前用途。
3. 最后看响应：同时记录 Response.Uncompressed、Content-Encoding、ContentLength，不要只打印 Body 长度。
4. 明确读取者：透明解压路径直接消费 Body；显式 gzip 路径由调用方创建 gzip Reader，并在所有错误路径关闭资源。

如果目标只是普通业务读取，保留 Transport 的透明解压通常最省心；如果目标是调试原始协议，就关闭自动协商；如果目标是自己控制编码，就把显式请求头、响应判断和解压责任放在同一个小模块内。这样“请求头行为变化”就不再是神秘副作用，而是配置和调用方责任共同决定的结果。

几个容易混淆的问题

DisableCompression=true 会删除我手动设置的 Accept-Encoding 吗？

不会。它主要阻止 Transport 在请求没有该字段时自动添加 gzip；调用方已经设置的请求头仍属于调用方协议选择。

看到 Uncompressed=true 还能读取 Content-Encoding 吗？

自动透明解压的路径中，相关编码字段会从暴露给业务的响应头语义中移除。判断是否透明解压应优先看 Response.Uncompressed，不要只靠编码字段。

为什么 ContentLength 变成 -1？

因为 Body 已经不是服务器直接发送的压缩实体，Transport 需要以解压后的流形式提供内容，原始压缩长度不能继续代表业务 Body 的长度。

显式请求 gzip 后一定要手动解压吗？

要先看响应的 Content-Encoding。如果服务端没有返回 gzip，就不应强行创建 gzip Reader；如果返回 gzip，则由调用方负责解压并处理 Reader 错误。

记住一句话就够了：DisableCompression 管的是 Transport 的自动协商，Response.Uncompressed 说明的是 Transport 是否完成了透明解压，而显式 Accept-Encoding 会把压缩响应的读取责任交回调用方。