gz.Close()不可省略，因其负责写入Gzip格式必需的CRC32校验值和原始长度（ISIZE），仅Flush()无法生成完整格式，会导致解压失败；必须配对defer gz.Close()并检查其error。
Gzip 压缩不是开个开关就完事，Go 里必须手动控制写入和关闭节奏，否则解压端会报 gzip: invalid checksum 或 unexpected EOF。
为什么 gz.Close() 不可省略？
gzip.Writer 是缓冲写入器，Write() 只把数据送进压缩管道，不输出完整格式。Gzip 格式要求末尾有 CRC32 校验值和原始长度（ISIZE），这些只在 Close() 时写入。用 Flush() 替代会失败——它只刷压缩块，不写尾部，标准解压工具（包括 Go 的 gzip.NewReader）直接拒收。
- 现象：返回的字节切片在
gzip.NewReader上 panic，或 Linuxzcat报 “invalid compressed data” - 场景：缓存响应体到 Redis、拼接 multipart 请求、生成预压缩静态资源
- 实操：所有
gzip.NewWriter后必须配对defer gz.Close()，且要检查gz.Close()的 error 返回，它可能因底层io.Writer写失败而报错
io.Copy(gz, r.Body) 是流式压缩的核心
它把 r.Body（io.ReadCloser）当源头，gz（io.Writer）当目标，边读边压，内存占用稳定，不依赖响应体大小。
- 别先
ioutil.ReadAll(r.Body)再压——大响应直接 OOM - 别用
bytes.Buffer.Write()手动喂数据后不Close()——常见于日志中间件误实现 - 示例关键段：
gz := gzip.NewWriter(&buf)<br>_, err := io.Copy(gz, r.Body)<br>if err != nil { return nil, err }<br>if err = gz.Close(); err != nil { return nil, err }
客户端发压缩请求时，Content-Length 必须是压缩后长度
http.Client 不会自动压缩，你塞什么它就发什么。设了 Content-Encoding: gzip 却没压缩数据，服务端一解压就崩。
- 错误写法：
req.Header.Set("Content-Length", strconv.Itoa(len(payload)))—— 这是原始长度 - 正确流程：先调
gzipRequestBody(payload)得到gzData []byte，再设Content-Length: len(gzData) - 注意：如果 payload 是
io.Reader（比如文件流），不能用bytes.Buffer中转，得用io.Pipe配合 goroutine 流式压，否则阻塞
服务端解压请求体要防 panic，gzip.NewReader 很挑输入
它只认完整 gzip 格式（magic bytes 0x1f 0x8b 开头），HTTP chunked 编码的分块头、多余换行、甚至空格都会导致 gzip: invalid header。
- 必须先确认
r.Header.Get("Content-Encoding") == "gzip"，再 wrapr.Body - 别直接传
r.Body给gzip.NewReader，先用io.ReadAll检查前几个字节是否合法（可选） - 务必
defer reader.Close()，否则连接复用时底层 reader 状态混乱 - 若服务端也用
net/http，建议统一加中间件拦截并替换r.Body，避免每个 handler 重复判断
最常被跳过的其实是 Close 的 error 检查——它不总为 nil，尤其当你把 gzip 写进网络连接或磁盘文件时，写满磁盘或连接中断都会在这里暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
