必须调用gzip.Writer.Close()或zlib.Writer.Flush()确保压缩流完整，否则buf.Len()失真；压缩比需用float64(len(src))/float64(buf.Len())计算，整数除法会截断致结果恒为1。
压缩比必须手动计算：原始字节数 ÷ 压缩后字节数，且全程基于 []byte 操作；用 gzip.Writer.Close() 或 zlib.Writer.Flush() 确保压缩流完整写出，否则 buf.Len() 返回值严重失真。
为什么不能直接用 len(src) / len(compressed)？
Go 的整数除法会截断小数部分，len(src) / len(compressed) 在大多数情况下结果为 1（哪怕 src 是 compressed 的 3 倍大）。必须至少一方转为浮点类型：
-
float64(len(src)) / float64(buf.Len())✅ -
float64(len(src)) / float64(len(compressed))✅（前提是compressed := buf.Bytes()已在Close()或Flush()后调用） -
len(src) / len(compressed)❌（整数除，永远错）
gzip 和 zlib 的关键操作差异
二者协议头尾不同，但压缩比计算逻辑一致；区别在于资源清理方式和方法名：
-
gzip.Writer必须调用.Close()—— 它负责写入 8 字节 trailer（含 CRC32），不调用则压缩数据不完整，buf.Len()偏小 -
zlib.Writer没有.Close()，只有.Flush()—— 必须显式调用，否则 Adler32 校验尾部缺失，部分解压器会拒绝 - 两者都需清空可选字段：
gw.Header.Name = ""、gw.Header.Comment = ""，避免额外 10–30 字节干扰 - 对小数据（
常见错误导致压缩比虚高或解压失败
这些不是“算得不准”，而是根本没压完或压错了对象：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Stat().Size()当原始长度 —— 文件可能已带 gzip header，或含 BOM、换行符等未清洗内容 - 对 JSON 字符串直接
json.Marshal(v)得到原始长度 —— 默认带空格/换行，应先用json.Compact()归一化 - 反复新建
gzip.NewWriter(&buf)并写小块数据 —— 每次新建重置 DEFLATE 上下文，失去重复模式识别能力，压缩比暴跌 - 用
bufio.Writer套在gzip.Writer外层再统计 ——Write()返回值反映的是 bufio 缓冲区写入量，非真实压缩字节数
真正影响压缩比的从来不是公式本身，而是你是否让压缩器看到完整的原始数据、是否让它把所有压缩字节都吐出来、以及是否在相同前提下对比——协议头、空白字符、缓冲策略，任何一个变量失控，比值就失去参考价值。
