gzip.NewWriterLevel压缩级别需按场景选择：HTTP响应用BestSpeed（1）兼顾速度与体积，日志流用DefaultCompression（6）并手动Flush，冷数据归档才用BestCompression（9），小数据（<1KB）压缩后可能膨胀。
gzip.NewWriterLevel 的压缩级别怎么选
压缩级别不是“越高越好”，而是要按数据特征和传输链路来卡点。Go 标准库把 gzip.BestSpeed（值为 1）到 gzip.BestCompression（值为 9）映射到底层 flate 的不同策略，影响的不只是速度，还有缓冲行为、锁争用和小包膨胀风险。
- HTTP API 响应体（几百字节 ~ 几 KB）：用
gzip.BestSpeed（1）——实测比默认级快 2.3×，体积只大 15–20%，但能避免小包下 gzip.Writer 内部锁成为瓶颈 - 日志流或监控指标推送（持续小块写入）：必须配
gzip.DefaultCompression（6）+ 手动Flush()，否则首字节延迟明显；BestSpeed在这种场景下反而因 header 开销占比高，压缩后体积不降反升 - 归档冷数据或离线文件打包：才考虑
gzip.BestCompression（9），但要注意耗时可能是 level 1 的 8 倍以上，而体积仅再降 3–5%
小数据压缩后变大的真实原因
gzip 协议头固定占 10 字节，DEFLATE 最小块也有开销；小于 1KB 的 payload 经 gzip.NewWriter 处理后，大概率比原文还大。这不是 bug，是协议设计使然。
- HTTP 服务中，Go
net/http从 1.19+ 起硬编码了 1.5KB 阈值：响应体小于该值直接跳过压缩，无法关闭 - gRPC 场景更敏感：单条 message 小于 1KB 时开启 gzip，压缩耗时 > 网络节省，且可能触发更多 TCP ACK，整体延迟上升
- 替代方案：对 zstd（
zstd.SpeedFastest在 256B 输入时仍保持 0.5x 压缩率，编码耗时比 gzip 低 40%）
并发写 gzip.Writer 必 panic
gzip.Writer 不是并发安全的，多 goroutine 往同一个实例写会触发 fatal error: concurrent write to gzip writer 或静默内存错误。
- 别用 channel 广播压缩结果——Go channel 不支持多读，且无背压；每个消费者应配独立
gzip.Writer - 若需复用（如高频小文件压缩），必须用
sync.Pool管理，每次取出后调Reset()绑定新io.Writer，用完立刻Close()再放回 pool - 常见陷阱：defer
Close()放在函数末尾，但中间出错后未Reset()就 return，导致下次从 pool 取出的状态混乱
没 Close() 导致解压端报 invalid checksum
gzip.Writer.Close() 不只是收尾动作，它负责写入 trailer（CRC32 + uncompressed length），缺了这个，接收方 gzip.NewReader 会校验失败，报 gzip: invalid checksum 或 unexpected EOF。
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 中：必须在
Write()后显式调gz.Close()，不能只靠 defer（error 分支容易漏） - 网络流场景（如 TCP 推送）：即使数据写完了，也要
Flush()+Close()，否则最后一块缓冲区卡在内存里 - 如果中途 abort，用
Reset()清状态，但注意它不重置底层io.Writer，已写入的部分不会回滚
gzip.Writer 时只 Reset() 没 Close()，或往已 Close() 的实例继续 Write()，这两种情况都不会 panic，但会导致数据损坏或静默丢弃——问题只在解压端暴露，排查成本极高。 
