必须调用gzip.Writer.Close()，否则缺失CRC32和ISIZE尾部校验信息，导致压缩数据不完整、解压失败，且压缩比虚高；小数据（
gzip.Writer.Close() 必须调用，否则压缩比失真
不调用 Close() 会导致 gzip 数据不完整：尾部校验字节（CRC32、ISIZE）缺失，解压时可能失败，更关键的是——你拿到的压缩后字节数偏小，算出的“压缩比”虚高。实测中未 Close() 的 bytes.Buffer 长度可能比真实 gzip 流少 8–12 字节，对小数据影响显著（比如原始 100B 字符串，误差可达 10%+）。
正确做法是写完数据后立刻 Close()，再读取底层 bytes.Buffer.Bytes()：
- 先
w := gzip.NewWriter(&buf) - 再
w.Write([]byte(data)) - 最后
w.Close()—— 这一步不可省略，也不可用defer延迟到函数末尾（除非你确定后续无其他逻辑依赖压缩结果）
压缩比公式要区分“原始字节”和“原始字符串长度”
Go 中字符串底层是 UTF-8 编码，len(s) 返回的是字节数，不是 rune 数。计算压缩比必须统一用字节维度，否则中文、emoji 场景下结果完全错误。例如 "你好" 的 len() 是 6（UTF-8 占 3 字节/字符），若误用 utf8.RuneCountInString() 得到 2，压缩比就变成 2 / compressedLen，毫无意义。
标准压缩比定义为：
compressionRatio = float64(len(originalBytes)) / float64(len(compressedBytes))
常见错误包括：
- 用
len(string)当作“字符数”参与计算 - 压缩前没转
[]byte，直接对 string 调用len()—— 其实没问题，因为 Go string header 里 length 就是字节数，但语义上建议显式转[]byte(s)避免混淆 - 解压后再比对长度验证 —— 不必要，压缩比只关心输入输出字节数，不校验内容一致性
gzip.SetLevel() 对压缩比影响极大，但默认值不透明
gzip.DefaultCompression 实际值是 -1，它不是固定级别，而是由 flate 底层决定的“自适应平衡点”，不同 Go 版本可能微调。如果你需要稳定可复现的压缩比（比如用于性能基准测试或归档一致性校验），必须显式设置级别：
-
gzip.BestSpeed（值为 1）：压缩比通常 1.1–1.3x，适合实时响应 -
gzip.DefaultCompression（值为 -1）：实测约 2.0–2.8x，通用推荐 -
gzip.BestCompression（值为 9）：压缩比可达 3.0–3.5x，但 CPU 时间翻倍以上
注意：同一份数据在不同 Go 版本下，即使设相同 level，因 flate 实现优化，压缩比也可能浮动 ±0.1x。如需跨版本一致，应锁定 Go 版本并记录 runtime.Version()。
小数据压缩可能“越压越大”
Gzip 有固定开销：至少 18 字节头部 + 8 字节尾部 = 26 字节。当原始数据小于这个阈值（比如空字符串、单个数字 "42"），压缩后反而更大。此时压缩比 是正常现象，不是 bug。
实用建议：
- 对
len([]byte) 的数据，跳过 gzip，直接用 raw bytes - 如果业务允许，可改用
compress/flate（无 gzip 头尾，开销仅 ~2 字节），但牺牲了跨语言兼容性 - 批量处理时，别单独压缩每个短字段；先拼接、加分隔符、再整体压缩，能显著提升小数据场景下的有效压缩比
真正容易被忽略的是：压缩比数值本身没有绝对意义，它高度依赖数据重复模式。一段全是随机字节的 []byte，无论用什么 level，压缩比都接近 1.0；而日志文本、JSON、XML 等结构化数据才体现差异。测压缩比前，先确认你的数据是否具备可压缩性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
