gzip.writer写入后必须调用close()以写入尾部校验信息，否则解压会失败；gzip.reader要求完整gzip格式输入，不支持裸deflate数据；压缩级别需按场景权衡性能与体积。
gzip.Writer 写入后必须调用 Close()，否则压缩数据不完整
Go 的 gzip.Writer 是缓冲写入器，它不会在每次 Write() 后立即 flush 压缩块。如果你只写完就丢弃 writer，底层 gzip 流缺少 EOF 标记和尾部校验字段（如 CRC32、ISIZE），解压端会报 unexpected EOF 或 invalid checksum。
- 务必在写入完成后调用
w.Close()—— 这一步会 flush 缓冲区、写入 gzip 尾部，并关闭底层io.Writer - 如果写入中途出错，也要 defer
Close()并检查其返回值，因为Close()本身可能返回压缩/写入错误 - 别用
Flush()替代Close()：它只 flush 当前压缩块，不写尾部，无法被标准 gzip 工具识别
gz := gzip.NewWriter(w)
_, err := gz.Write(data)
if err != nil {
return err
}
if err = gz.Close(); err != nil { // 关键！
return err
}
gzip.Reader 要求输入流以完整 gzip 格式开头，不能直接读“裸”压缩数据
Go 的 gzip.Reader 严格校验 gzip 文件头（magic bytes 0x1f 0x8b）和后续结构。如果你传入的是去掉 header/trailer 的纯 deflate 数据（比如某些 C 库或 HTTP Content-Encoding: deflate 场景），gzip.NewReader() 会直接 panic 或返回 gzip: invalid header。
- 确认数据来源：HTTP 响应头是
Content-Encoding: gzip才能放心用gzip.NewReader() - 如果后端发的是 raw deflate（无 gzip 封装），得改用
zlib.NewReader()或flate.NewReader()，并注意协议差异 -
gzip.NewReader()不会自动跳过非 gzip 前缀；如果数据前面有其他协议头（如 HTTP chunked 编码的长度行），需先剥离再喂给它
设置 gzip.NewWriterLevel() 的压缩级别要权衡 CPU 和体积
默认级别 gzip.DefaultCompression（=6）是通用平衡点，但实际场景中常需要调整：日志上传可设为 gzip.NoCompression（=0）保速度；归档导出可设 gzip.BestCompression（=9）省带宽，但 CPU 占用翻倍。
- 级别 1–3：适合实时流（如 WebSocket 消息），压缩率低但延迟小，内存占用稳定
- 级别 7–9：压缩率提升边际递减，但 CPU 时间和 GC 压力明显上升，尤其在小 buffer（
- 避免在循环中反复新建
gzip.Writer：复用实例 +Reset(io.Writer)更高效，且能保持内部字典状态（对短文本连续压缩有帮助）
HTTP 服务中启用 gzip 响应要注意 Content-Length 和流式响应冲突
一旦用 gzip.NewWriter 包裹 http.ResponseWriter，你就失去了预知压缩后长度的能力，所以不能提前写 Content-Length header。强行设置会导致浏览器截断或解析失败。
立即学习“go语言免费学习笔记（深入）”；
- 标准做法：不设
Content-Length，依赖Transfer-Encoding: chunked—— Go 的http.Server在检测到未设置Content-Length且 ResponseWriter 支持 flush 时会自动启用 chunked - 如果必须用
Content-Length（如某些老旧代理要求），只能先压缩到bytes.Buffer，再写 header 和 body，但会丧失流式优势，增加内存峰值 - 别在 handler 里对同一个
ResponseWriter混用 gzip 和非 gzip 写入：writer 状态不可逆，第二次Write()可能 panic 或静默失败
gzip.Writer.Close() 的调用时机，以及把非标准 deflate 数据误当 gzip 输入。 
