压缩比=原始字节长度÷压缩后字节长度；需基于完整[]byte操作，调用gzip.Writer.Close()确保校验和写入，清空Header.Name/Comment避免额外开销，并用bytes.Buffer.Len()准确获取压缩后大小。
直接算原始字节长度除以压缩后字节长度，就是压缩比；但要注意边界条件和数据代表性。
怎么用 compress/gzip 或 compress/flate 计算真实压缩比
压缩比不是调用一次 Write 就能准确反映的——它高度依赖输入数据的重复性、长度和内容分布。实际计算必须基于完整、可复现的输入样本：
- 用
bytes.Buffer接收压缩输出，避免中间截断或隐式 flush - 务必调用
Writer.Close()，否则尾部校验和未写入，Buffer.Len()偏小，压缩比虚高 - 对同一份原始数据（比如 1MB 日志文本），分别用
gzip.NewWriter和flate.NewWriter压缩，再对比buf.Len() - 不要用空字符串或极短数据（如
"a"）测压缩比：gzip 头部固定占 10+ 字节，此时压缩比可能为负数（压缩后反而更大）
为什么用 gzip 算出来的压缩比和用命令行 gzip -l 不一致
Go 的 gzip.Writer 默认不写文件名、修改时间等元信息（即使用 gzip.Header 的默认零值），而命令行 gzip 默认会写完整头。这会导致：
- Go 压缩结果比命令行小 10–20 字节（纯数据流模式）
- 若需对齐命令行行为，得手动设置
w.Header.Name和w.Header.ModTime，再调用w.Reset() - 更关键的是：命令行
gzip -l file.gz显示的是“压缩后大小 / 原始未压缩大小”，而 Go 中你控制的是原始输入，所以必须自己记录原始[]byte长度，不能依赖文件系统 stat
压缩比受哪些参数影响最明显
同一段数据，不同配置下压缩比可能差 20% 以上：
-
gzip.BestSpeed（级别 1）通常比gzip.BestCompression（级别 9）压缩比低 15–30%，但快 3–5 倍 -
flate.NewWriter允许传入dict []byte（预置字典），对结构化日志或协议报文可提升 5–10% 压缩比，但gzip.Writer不支持字典 - 小数据块（gzip.NewWriterLevel(w, gzip.NoCompression) 可跳过压缩逻辑，仅打包头部——此时压缩比恒为 ~0.9（因头部开销）
别忽略解压后的数据一致性验证
压缩比再高也没用，如果解出来数据错了。必须做 round-trip 校验：
- 压缩前计算
crc32.ChecksumIEEE(src) - 解压后对输出再算一次 crc32，比对是否相等
- 尤其注意：用
gzip.NewReader解压时，若输入是截断的 gzip 流，Read可能不报错但返回部分数据——要检查err == io.EOF才算完整解压成功 - 不建议只靠
len(src) == len(dst)判断，二进制内容错位时长度可能碰巧一致
压缩比是个表观指标，真正关键的是「在目标场景下，这个比值是否稳定、可复现、且解压后数据零误差」。测的时候别只跑一次，至少用三组不同特征的数据（纯文本、JSON、二进制日志）交叉验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
