压缩比并非越高越好，应关注单位CPU时间换来的字节节省；对JSON日志，gzip.BestCompression仅多省8%但耗时翻倍，zstd.SpeedFastest通常更优；计算真实压缩比需扣除header开销（如gzip 10字节、zstd 2～4字节），尤其对短字符串。
压缩比不是越高压越好，盲目追求高比会拖垮吞吐、挤爆内存；真正要盯的是「单位CPU时间换来的字节节省」——对JSON日志这类高冗余文本，gzip.BestCompression可能只多省8%空间，但耗时翻倍；而zstd.SpeedFastest在多数场景下已够用。
怎么算准压缩比，而不是被header骗了
gzip、zstd等格式会在压缩数据前加固定长度header（gzip 10字节，zstd最小2～4字节），短字符串（len(s) ）压缩后反而更大。实测一个128字节的UUID字符串，用gzip.BestCompression压缩后变成142字节。
- 正确计算方式：
(float64(len(raw)) - float64(len(compressed))) / float64(len(raw))，务必用原始字节长度，别用string转码后的rune数 - 避免用
bytes.Buffer.Len()直接当压缩后大小——如果没调Close()，gzip.Writer内部缓冲区还没flush，结果偏小 - 对
compress/flate底层压缩器，可设flate.HuffmanOnly跳过LZ77匹配，适合极短文本（
为什么gzip.DefaultCompression常比BestCompression更优
Go标准库compress/gzip中，DefaultCompression（-1）实际启用动态级别策略：对小块数据自动降级为BestSpeed，大块才尝试深度匹配。实测1MB JSON在i7-11800H上：
-
BestCompression：耗时 94ms，压缩后 327KB -
DefaultCompression：耗时 41ms，压缩后 335KB（仅多占 8KB，快 2.3×） -
BestSpeed：耗时 18ms，压缩后 372KB（多占 45KB，但P99延迟压到 22ms）
业务若对延迟敏感（如API响应），DefaultCompression是默认安全选择；只有归档类离线任务才值得上BestCompression。
zstd压缩比优化的关键参数不是Level，而是WindowSize
zstd的压缩比强依赖滑动窗口大小。默认WindowSize=1MB，对长文本（如2MB日志）无法跨块匹配重复段；但盲目拉到8MB又会导致单次EncodeAll()内存暴涨。
- 推荐做法：按典型输入长度设
WithWindowSize(1（1MB）或WithWindowSize(2（2MB），不超预期最大值的1.5× - 用
zstd.Encoder复用实例时，必须调Reset(io.Writer)而非新建——否则每次初始化窗口结构体，GC压力陡增 - 别用
zstd.EncodeAll([]byte, []byte, nil)直接传大slice：它内部会make([]byte, 0, len(src)*2)，OOM风险高；应配zstd.WithEncoderBufferPool+sync.Pool管理输出缓冲区
真正卡住压缩比上限的，往往不是算法本身，而是你传给它的数据边界——比如把10个独立JSON拼成一个大字符串再压，不如单个压完再append二进制块；后者能保留各块独立的Huffman树，实际压缩率反而更高。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
