必须调用gzip.Writer.Close()才能写出完整gzip流，否则缺失CRC校验和ISIZE字段导致解压失败；流式压缩需边写边压、避免全量加载内存，解压时应直接用gzip.NewReader包装原始io.Reader而非预读全部数据。
golang 中用 gzip.Writer 做流式压缩，别等数据攒够再写
流式压缩的核心是边读边压、边压边写，不把整个 payload 加载进内存。Go 标准库的 gzip.Writer 天然支持这个模式，但关键在于别调用 Close() 太早——它会 flush 并写入 gzip 尾部（含校验和），提前关会导致解压失败。
常见错误：把 bytes.Buffer 或 io.Pipe 当成“中间容器”反复 Write 后再统一压缩，这反而失去流式意义；或者忘记在写完后显式 Close()，导致尾部缺失，gzip: invalid header 就这么来的。
- 压缩端：用
gzip.NewWriter(io.Writer)包裹目标写入器（如http.ResponseWriter、文件、网络连接），直接Write([]byte)即可 - 必须在所有数据写完后调用
gzipWriter.Close()，否则输出不完整 - 如果目标写入器本身有缓冲（如
bufio.Writer），建议把它包在gzip.Writer外层，避免双缓冲拖慢吞吐
解压时用 gzip.NewReader 接 io.Reader，别试图预读整个 body
gzip.NewReader 接收任意 io.Reader，包括 http.Request.Body、文件句柄、甚至管道输出。它内部按需读取并解压，不会一次性加载全部压缩数据——这才是真正的流式解压。
典型翻车点：先用 io.ReadAll(r) 把压缩数据全读进 []byte，再传给 gzip.NewReader(bytes.NewReader(data))。这不仅浪费内存，还破坏了流式语义；更糟的是，如果原始数据来自 HTTP 请求且没设 Content-Encoding: gzip，服务端可能根本没压缩，你硬解就会报 gzip: invalid checksum 或 invalid header。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 直接传原始 reader：
gr, err := gzip.NewReader(httpReq.Body)，后续用gr.Read()或io.Copy(dst, gr) - 务必检查
err—— 如果 reader 开头不是 gzip magic bytes（0x1f 0x8b），NewReader会立即返回错误 - 解压完成后记得
gr.Close()，它会关闭底层 reader（除非你传的是io.NopCloser包装的）
HTTP 场景下压缩/解压要手动控制 Content-Encoding 头
net/http 默认不自动解压请求体，也不自动压缩响应体。你得自己加逻辑，否则客户端发来的 gzip 数据会被当纯文本处理，或者你返回的 gzip 数据被浏览器当成乱码。
容易忽略的细节：HTTP 头大小写不敏感，但 Go 的 Header.Set 会规范化 key；而判断是否需要解压，不能只看 header key 是否存在，还得确认值是 gzip（不是 GZIP 或 gzip, deflate 这种复合值）。
- 响应压缩：写响应前设
w.Header().Set("Content-Encoding", "gzip")，再用gzip.NewWriter(w)写内容 - 请求解压：读
r.Header.Get("Content-Encoding")，若等于"gzip"，则用gzip.NewReader(r.Body)替换r.Body - 注意：修改
r.Body后，如果后续还要用r.ParseForm()等方法，需确保解压 reader 可重放（标准gzip.Reader不支持 seek，此时应先io.ReadAll解压到内存再重包）
性能与边界：小数据不值得压缩，大文件慎用默认 gzip.BestSpeed
gzip 默认使用 gzip.DefaultCompression（等级 6），对小块数据（比如几 KB 的 JSON）压缩收益极低，反而因 CPU 开销和 header 开销导致整体变慢。而超大文件（GB 级）用 gzip.BestCompression（等级 9）可能卡住 goroutine，影响并发。
另一个坑是：gzip.Writer 内部缓冲区默认 4KB，如果写入极小片段（如每次 1B），频繁 flush 会导致 syscall 过多；但设太大又增加延迟。
- 小数据（zlib（header 更小）
- 高吞吐场景（如日志转发）：用
gzip.NewWriterLevel(dst, gzip.BestSpeed)（等级 1）换取更低延迟 - 需要精确控制缓冲：用
gzip.NewWriterLevel(dst, level)+gzipWriter.Reset(dst)复用 writer 实例，避免频繁 alloc
