缓存数据压缩比必须手动计算，即原始[]byte长度÷压缩后bytes.buffer.len()；需调用close()或flush()确保字节完整写出，不可用os.stat().size()误读文件头或忽略编码差异。
缓存数据压缩比必须手动计算，不能依赖库函数返回值；核心是用原始 []byte 长度除以压缩后 bytes.Buffer.Len()，且必须调用 Close() 或 Flush() 确保字节完整写出。
为什么不能直接用 len() 对比文件大小
缓存数据通常在内存中流转，不是磁盘文件。用 os.Stat().Size() 会误读已带 gzip header 的 .gz 文件（多出 10+ 字节），或忽略编码差异（如 JSON 中 & 被转义为 \u0026）。真实压缩比只对同一份 []byte 的“输入”和“输出”有意义。
- 原始数据必须先完整读入内存（例如从 Redis
GET返回的[]byte） - 避免对
string类型直接调用len()——它返回 UTF-8 字节数，但若原始缓存是 base64 编码的二进制，len(string)≠len([]byte) - 若缓存值是 JSON，记得用
json.Encoder.Encode()后bytes.TrimSuffix(..., []byte{'\n'})去掉尾部换行，否则小数据下误差可达 10%
gzip 和 zlib 的压缩比不能混用比较
同样一段 []byte，用 compress/gzip 和 compress/zlib 压缩后长度不同：gzip 协议头尾共 18 字节（10+8），zlib 是 6 字节（2+4）。对小数据（1MB），两者比值才趋近一致。
- 选 gzip：适合 HTTP 传输、兼容性要求高（浏览器/CDN 普遍支持）
- 选 zlib：适合内部 RPC 流、协议栈已封装好校验逻辑的场景
- 别在同一个 benchmark 里交叉测试两者——这不是算法优劣问题，是协议头尾的硬差异
实时监控缓存压缩比的陷阱
想在缓存写入时打印当前压缩比？gzip.Writer 不暴露内部状态，无法边写边算。强行每写一次就调 buf.Len()，结果要么是 0（缓冲未刷出），要么跳变剧烈（首几 KB 显示 “100%” 或负值）。
- 正确做法：用
io.MultiWriter包裹一个计数器 +gzip.Writer，原始字节数靠计数器累加，压缩字节数靠bytes.Buffer.Len()定期读取 - 必须复用同一个
*gzip.Writer实例——反复NewWriter会重置 DEFLATE 上下文，压缩比失真 - 别在循环里调
Close()：它会写入 trailer 并清空状态，下次Write()相当于新流，失去上下文增益
最易被忽略的一点：压缩比数字本身没意义，关键看数据特征。重复字段名的 JSON、纯文本日志能压到 30%–50%，而已 base64 的图片、加密 token、随机 UUID 基本不压缩，甚至略膨胀。别为“压不动”的缓存强行套 gzip——加个 if len(data) > 512 守门逻辑更实际。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
