必须调用gzip.Writer.Close()才能写入CRC32校验和与ISIZE等尾部信息，否则压缩流不完整，导致解压失败或压缩比虚高；手动计算压缩比时，未Close()会使压缩后长度异常偏小，结果失真。
Go语言中没有内置的“压缩比计算函数”，压缩比必须手动计算：用原始数据长度除以压缩后数据长度。 这个比值本身不依赖任何库，但它的准确性完全取决于你是否正确完成压缩流程——尤其是 Close() 是否被调用、底层写入器是否清空、是否遗漏尾部校验信息。
为什么 gzip.Writer.Close() 不调用会导致压缩比虚高
未调用 Close() 时，gzip.Writer 内部缓冲区中的待压缩数据和 gzip 文件尾部（包含 CRC32 校验和、ISIZE 字段等）不会写入底层 io.Writer。此时读取 bytes.Buffer.Bytes() 得到的是不完整、不可解压的数据，长度偏小，导致计算出的压缩比远高于真实值。
- 现象：同一段数据，不
Close()时压缩后只有 20 字节；调用后变成 48 字节，压缩比从 50→20 倍骤降 - 原因：gzip 格式强制要求尾部 8 字节元信息，缺了就不是合法 gzip 流
- 正确姿势：必须
defer gw.Close()或在Write()后显式调用，且要检查Close()返回的error
compress/flate 和 compress/gzip 的压缩比差异来源
compress/flate 只实现 DEFLATE 算法本体，无头部/尾部封装；compress/gzip 在其上加了 10+ 字节固定头部和 8 字节尾部。因此相同数据、相同压缩级别下，gzip 输出一定比 flate 多约 18 字节。
- 适用场景：
flate适合内部 RPC 通信（双方约定裸 DEFLATE 流），gzip用于 HTTP、文件存储等需跨系统兼容的场景 - 压缩比影响：小数据（
- 验证方式：用
gzip.NewReader解压flate.Writer输出会失败，报gzip: invalid header
如何安全复用 gzip.Writer 计算多次压缩比
反复创建新 gzip.Writer 开销低，但若追求极致性能（如高频日志采样），可复用实例——前提是每次压缩前重置底层 bytes.Buffer 并重新初始化 gzip.Writer 状态。
立即学习“go语言免费学习笔记（深入）”；
- 错误做法：直接对同一
gzip.Writer多次Write()，不Close()也不重置，输出会叠加、损坏 - 正确做法：调用
buf.Reset()清空缓冲区，再用gzip.NewWriter(&buf)创建新 writer（不能复用旧指针） - 注意：无法通过
Reset(io.Writer)重置已关闭的gzip.Writer，标准库不支持该方法
压缩比数字本身容易误导——它不反映解压速度、CPU 占用或内存峰值。真正关键的是：你是否在 Close() 后才读取长度？是否混淆了 flate 与 gzip 的格式边界？这些细节一旦出错，比值再高也没意义。
