Go的http.Client不会自动压缩请求体，需手动gzip压缩数据并设置Content-Encoding: gzip和正确的Content-Length。
Go 的 http.Client 默认不自动压缩请求体
很多人以为设置 Content-Encoding: gzip 后，http.Client 会自动帮你压缩 Body，其实不会。它只负责透传你塞进去的字节流。如果你手动加了头但没压缩数据，服务端解压会失败，常见错误是 gzip: invalid header 或直接 400/500。
真正要实现「请求压缩」，必须自己把原始 payload 用 gzip 压缩，并显式设置两个关键字段：
Content-Encoding: gzip-
Content-Length（必须是压缩后字节长度，不能沿用原始长度）
注意：不要用 bytes.Buffer 直接写 gzip 流再读取，容易因未关闭 gzip.Writer 导致尾部校验字节缺失——这是最常踩的坑。
手动压缩请求体的可靠写法（net/http + compress/gzip）
核心是用 gzip.NewWriter 包裹一个可寻址的缓冲区（如 bytes.Buffer），写入原始数据后调用 Close()，再读取压缩结果。
立即学习“go语言免费学习笔记（深入）”；
func gzipRequestBody(data []byte) ([]byte, error) {
var buf bytes.Buffer
gw := gzip.NewWriter(&buf)
if _, err := gw.Write(data); err != nil {
return nil, err
}
if err := gw.Close(); err != nil { // 必须 close，否则 gzip 流不完整
return nil, err
}
return buf.Bytes(), nil
}
// 使用示例
payload := []byte({"name":"alice","score":99})
gzData, _ := gzipRequestBody(payload)
req, _ := http.NewRequest("POST", "https://www.php.cn/link/d023b1ef80754864db9e412e1fd955ac", bytes.NewReader(gzData))
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Content-Encoding", "gzip") // 显式声明
req.Header.Set("Content-Length", strconv.Itoa(len(gzData))) // 设置真实长度
client := &http.Client{}
resp, _ := client.Do(req)
服务端如何正确解压 gzip 请求（http.Handler 场景）
客户端压了，服务端得能解。Go 标准库没有自动解压中间件，需手动判断 Content-Encoding 并包装 Request.Body。
关键点：
- 只处理
Content-Encoding: gzip，忽略deflate等其他编码（除非你明确支持） - 解压失败时，应返回
400 Bad Request而非静默丢弃 - 解压后记得重置
Content-Encoding和Content-Length（后者设为 0 或删掉）
func decompressBody(r *http.Request) error {
enc := r.Header.Get("Content-Encoding")
if enc != "gzip" {
return nil
}
gz, err := gzip.NewReader(r.Body)
if err != nil {
return fmt.Errorf("invalid gzip body: %w", err)
}
defer gz.Close()
// 替换 Body 为解压流
r.Body = ioutil.NopCloser(gz)
r.Header.Del("Content-Encoding")
r.Header.Del("Content-Length") // 解压后长度未知，由上层读取决定
return nil}
// 在 handler 中调用
func myHandler(w http.ResponseWriter, r *http.Request) {
if err := decompressBody(r); err != nil {
http.Error(w, "bad compressed body", http.StatusBadRequest)
return
}
// 此时 r.Body 已是解压后的原始流，可正常 json.Decode
}
别用 http.Transport 的 DisableCompression 来“启用压缩”
这个字段名字极具误导性：DisableCompression 控制的是 **响应体** 是否自动解压（即是否透传 Content-Encoding: gzip 的响应），跟请求体完全无关。设成 false 不会让请求变压缩，设成 true 也不会阻止你手动发压缩请求。
常见误操作：
- 以为设置了
transport.DisableCompression = false就能“开启请求压缩” → 实际毫无影响 - 在请求里漏掉
Content-Encoding头，却指望 transport 自动补 → 不会 - 用
io.Pipe配合gzip.Writer流式上传大文件，但没处理好 reader goroutine 的生命周期 → 容易死锁
真正需要流式压缩上传（比如上传大日志文件），应该用 io.MultiReader 或显式启动 goroutine 控制 gzip.Writer 写入，而不是依赖 transport。
