gzip.writer默认用level 6压缩率偏低，应按需选bestspeed(1)或bestcompression(9)；需复用sync.pool、手动处理accept-encoding/content-encoding、正确设置缓冲顺序（bufio→gzip）、调用close()确保trailer完整。
gzip.Writer 默认不启用最佳压缩级别
Go 的 gzip.Writer 默认使用 gzip.DefaultCompression（即 level 6），对文本类 payload 压缩率偏低，尤其在 API 响应、日志流、JSON 数据推送等场景下，带宽节省未达预期。
实操建议：
- 显式传入
gzip.BestSpeed（1）或gzip.BestCompression（9）——前者适合高并发低延迟服务，后者适合离线导出、后台任务 - 避免在每次 HTTP 响应中新建
gzip.Writer：复用sync.Pool可减少 GC 压力，尤其在 QPS > 1k 时明显 - 注意：level 9 并非总是“更好”——它会显著增加 CPU 占用，实测 JSON 响应压缩从 6→9，CPU 使用率可能翻倍，而体积仅再降 3%～5%
HTTP 响应中启用 gzip 需手动处理 Accept-Encoding 和 Content-Encoding
net/http 不自动压缩响应体；即使客户端声明支持 gzip，服务端仍需自己判断、包装、设置 header。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 写了
w.Header().Set("Content-Encoding", "gzip")，但没真正用gzip.Writer写响应 → 返回乱码或空响应 - 忽略
Accept-Encoding检查，对不支持 gzip 的客户端（如某些嵌入式设备、旧爬虫）也强制压缩 → 对方解析失败 - 压缩后未重置
Content-Length，导致 HTTP/1.1 连接异常关闭
正确做法：
- 先检查
r.Header.Get("Accept-Encoding")是否包含"gzip" - 用
gzip.NewWriter(w)包裹http.ResponseWriter，并在写完后调用gz.Close() - 不要手动设
Content-Length：gzip 流是 chunked 的，应让底层自动处理
流式压缩大文件时，bufio.Writer 缓冲层必须放在 gzip.Writer 外侧
顺序错位会导致压缩率暴跌或内存暴涨。典型错误是：gzip.Writer → bufio.Writer → os.File，这会让 gzip 每次只收到几字节，无法有效建 Huffman 表。
正确链路必须是：bufio.Writer → gzip.Writer → io.Writer（如 net.Conn 或 file）。
为什么这样做：
-
bufio.Writer负责攒批（默认 4KB），给gzip.Writer提供足够长的输入块，提升压缩效率 - 若反过来，
gzip会频繁 flush 内部状态，产生大量低效小 block，实测压缩比下降 20%～40% - 在 HTTP 流式响应中，可省略
bufio.Writer（因http.ResponseWriter自带缓冲），但文件导出、日志归档等 IO 密集场景必须加
gzip.Reader 解压失败常因 io.EOF 提前终止或 header 校验失败
消费方用 gzip.NewReader 解压时，容易遇到 unexpected EOF 或 invalid header，尤其在 TCP 长连接、HTTP 分块传输、自定义协议包中。
关键原因和应对：
- 发送方未调用
gzip.Writer.Close()→ gzip 流缺少 trailer（CRC32 + length），接收方解压到末尾报unexpected EOF - 接收方读取不完整：比如只读了前 N 字节就中断，后续再读新
gzip.Reader实例会因 magic number 错误报invalid header - 跨语言兼容问题：Java/Python 默认写 full header，Go 的
gzip.Writer也兼容，但若对方用了 zlib 封装（非 RFC 1952），需改用zlib.NewReader
建议始终 wrap 解压逻辑并检查 err == io.EOF 是否发生在 Read() 中途——如果是，说明数据流被截断，不是压缩格式问题。
流式场景下，别依赖单次 io.Copy 完成解压；用循环 Read + 显式 Close 更可控。
