压缩比计算必须用原始字节长度而非字符数，Go中len("中文")返回UTF-8字节数（如6），误用rune长度会导致分母偏小、压缩比虚高甚至超100%；gzip.Writer须显式Close()以写入完整数据并校验，未Close则解压失败。
压缩比计算必须用原始字节长度，不是字符串长度
Go里 len("中文") 返回的是 UTF-8 字节数（比如 6），但如果你误用 len("中文") 当作“字符数”去算压缩比，结果会严重失真。压缩操作处理的是字节流，不是 rune 或字符抽象。
常见错误现象：压缩后体积反而“变大”，实际是原始长度取错了——比如把 len([]rune(s)) 当作原始大小，导致分母偏小，压缩比虚高甚至 >100%。
- 正确做法：原始数据一律用
len([]byte(s))或直接传入[]byte类型 - 如果原始数据来自
io.Reader，先读到bytes.Buffer再取.Len()，避免多次读取 - 注意：
strings.Count(s, "") - 1这类 trick 不可靠，不适用于含 null 字节或二进制数据
gzip.Writer 必须 Close() 才能拿到完整压缩数据
不调用 Close() 就读 bytes.Buffer.Bytes()，得到的只是未刷新的中间状态，gzip 尾部校验（CRC、ISIZE）缺失，解压时大概率报 gzip: invalid checksum 或直接 panic。
这个坑在 benchmark 中尤其隐蔽：因为测试循环快，缓冲区残留可能偶然“看起来能解”，但生产环境必现。
立即学习“go语言免费学习笔记（深入）”；
- 写法上优先用
defer gz.Close()，但注意 defer 在函数 return 前才执行，若中间 panic 可能跳过 - 更稳妥：显式
if err := gz.Close(); err != nil { ... } - 不要复用
*gzip.Writer实例来算多次压缩比——每次 new 新实例，否则内部状态污染
压缩级别影响比值，但默认 DefaultCompression 已足够平衡
设置 gzip.BestCompression 确实能提升压缩比，但对中小文本（BestCompression 比 DefaultCompression 仅多压出 1.2%，耗时却增加 3.8×。
真正需要调级别的场景极少：日志归档（离线）、冷数据批量压缩。HTTP 响应、RPC payload 这类实时路径，BestSpeed 或默认值更合理。
- 别在循环里反复调
SetLevel()，它只在首次 write 前生效；改级别必须新建*gzip.Writer - 想对比不同级别效果？用固定输入 + 固定
bytes.Buffer，分别 new、write、close、取.Len() - 注意：
gzip.DefaultCompression是 -1，不是 6；传错数值（如传 0）会触发gzip: invalid compression level
flate.Writer 更轻量，但格式不兼容 gzip
如果你只关心压缩比数字本身，且不需要跨语言/跨系统解压，compress/flate 的 flate.Writer 是更快的选择：无 gzip 头尾开销，压缩启动延迟更低，同等数据下通常比 gzip 小 1–3%。
但它输出的是 raw DEFLATE 流，不是 RFC 1952 标准的 gzip 格式。浏览器、curl、gunzip 都无法直接解——除非你控制两端协议。
- 用
flate.NewWriter替代gzip.NewWriter时，务必确认下游能接受 raw deflate - HTTP 场景禁用：标准要求
Content-Encoding: gzip必须是完整 gzip 格式 - 内网服务间通信可考虑，但需显式约定 format 字段，避免和 gzip 混淆
压缩比本身是个简单除法，但背后每一步都卡在 Go 的 IO 抽象细节里：Writer 生命周期、字节 vs 字符、格式头尾、级别语义……最容易被忽略的是——你算出来的“压缩比”，到底是在模拟哪个真实使用场景。
