Go 的 http.Client 默认支持 gzip 压缩响应，前提是请求头含 Accept-Encoding: gzip 且服务端返回 Content-Encoding: gzip；此时 Transport 自动解压，Response.Body 为明文。
Go 的 http.Client 默认支持 gzip 压缩吗？
支持，但仅限于服务端返回 Content-Encoding: gzip 且客户端在请求头中明确声明接受时。Go 标准库的 http.Transport 默认启用了对 gzip 的自动解压——只要你在请求头里加了 Accept-Encoding: gzip，收到 gzip 响应后，Response.Body 会自动解压，你读到的就是原始明文内容。
注意：这个行为是「默认开启」的，无法关闭（除非自定义 Transport 并禁用 DisableCompression），但前提是服务端真的返回了 gzip 编码，且响应头匹配。
- 不手动加
Accept-Encoding: gzip→ 大多数服务端不会返回压缩内容 - 手动加了但服务端没压缩 → 响应正常，无副作用
- 服务端返回
gzip但你没加Accept-Encoding→ 可能返回乱码或解析失败（因未触发标准库自动解压逻辑）
如何手动控制 gzip 压缩请求体（POST/PUT）？
标准 http.Client 不会自动压缩请求体，必须自己处理。常见场景是向 API 提交大量 JSON 数据，希望减少带宽占用。
做法是：用 gzip.Writer 包裹原始数据，设置请求头 Content-Encoding: gzip，并确保服务端能识别和解压。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
var buf bytes.Buffer
gz := gzip.NewWriter(&buf)
json.NewEncoder(gz).Encode(data)
gz.Close() // 必须调用，否则数据可能未刷新
req, _ := http.NewRequest("POST", url, &buf)
req.Header.Set("Content-Encoding", "gzip")
req.Header.Set("Content-Type", "application/json")
- 忘记调用
gz.Close()→ 请求体为空或截断 - 设置了
Content-Encoding: gzip但服务端不支持 → 返回 415 或 500 - 压缩后没重置
Content-Length→ 多数情况 Go 会自动计算，但若用bytes.Reader等需注意底层长度是否准确
遇到 gzip: invalid header 错误怎么办？
这个错误几乎都发生在你试图手动解压响应体时——比如绕过了标准库自动解压，直接读 Response.Body 并用 gzip.NewReader 解压，但响应其实没压缩，或者被自动解压过一次了。
- 检查响应头：
resp.Header.Get("Content-Encoding")是否真为gzip - 确认没重复解压：如果没设
DisableCompression: true，Response.Body已是解压后的内容，再套gzip.NewReader必然报错 - 调试时建议先打印原始响应头和前 32 字节：
io.CopyN(ioutil.Discard, resp.Body, 32)（注意：读过之后 body 就不可再读）
需要支持 zstd、brotli 等非标准压缩算法怎么办？
Go 标准库只内置支持 gzip 和 flate（deflate），zstd、brotli、snappy 都需第三方库，且必须手动集成编解码逻辑。
以 zstd 为例（使用 github.com/klauspost/compress/zstd）：
import "github.com/klauspost/compress/zstd"
// 请求体压缩
encoder, _ := zstd.NewWriter(nil)
compressed := encoder.EncodeAll(data, nil)
req, _ := http.NewRequest("POST", url, bytes.NewReader(compressed))
req.Header.Set("Content-Encoding", "zstd")
- 服务端必须明确支持该编码，且双方压缩参数（如字典、级别）要一致
- 不能依赖标准库自动处理，所有压缩/解压逻辑都要显式写，包括错误处理和内存复用
- 注意：HTTP/2 虽支持多种编码协商，但实际兼容性取决于服务端实现，别假设浏览器或 nginx 一定支持
zstd
真正容易被忽略的是：压缩收益和 CPU 开销的平衡。小数据（
