压缩比核心公式为原始字节长度除以压缩后字节长度，陷阱在于必须统一用UTF-8字节长度比较，string需转[]byte再取len，压缩后用buf.Len()而非cap，且避免对空或极短数据计算。
压缩比计算的核心公式和陷阱
压缩比不是 Go 语言内置概念，它只是个简单算术比值：原始字节长度 / 压缩后字节长度。但很多人一上来就用 len([]byte(str)) 当原始大小，结果出错——因为没考虑编码。比如含中文的字符串，len("你好") 返回 6（UTF-8 编码下），而如果误用 len("你好") 当“字符数”去比，压缩比就完全失真。
真正该比的是**原始二进制数据大小**和**压缩后二进制数据大小**，两者单位必须一致（都是 int 类型的字节数）。
- 原始数据源必须明确：是
[]byte？还是string？若为string，先转成 UTF-8 字节切片（[]byte(s)）再量长度 - 压缩后数据必须是实际写入的字节数，不能依赖缓冲区容量（
buf.Cap()），而要用buf.Len() - 别对空数据或极短内容（如
"a"）算压缩比——gzip 可能反而更大（因 header 开销），这时比值会，属正常现象
用 gzip.Writer 计算真实压缩后大小
Go 标准库 compress/gzip 不直接返回压缩后长度，得靠 bytes.Buffer 捕获输出流再查 Len()。常见错误是调用 Close() 前不刷新，导致尾部数据没写入缓冲区，Len() 偏小。
正确做法：
立即学习“go语言免费学习笔记（深入）”；
var buf bytes.Buffer gz := gzip.NewWriter(&buf) _, _ = gz.Write(src) // src 是 []byte _ = gz.Close() // 必须调用！否则最后 block 没 flush compressedSize := buf.Len()
-
gz.Close()不仅结束压缩，还强制写出 trailer 和 checksum，缺它buf.Len()少 8–12 字节 - 不要用
gz.Write()的返回值（写入字节数）代替压缩后大小——那是原始输入长度，不是压缩结果 - 若需多次压缩不同数据，每次都要新建
gzip.Writer，复用会导致状态污染
处理文件压缩比时的路径与错误检查
读文件算压缩比时，容易忽略 I/O 错误和文件为空的情况。比如 os.ReadFile("data.txt") 失败却继续计算，会导致 panic 或错误比值。
- 务必检查
err：读取失败、写入失败、gzip.Close()失败都可能影响结果 - 文件路径要传绝对路径或确保工作目录正确，相对路径在 CLI 工具中极易出错；建议用
filepath.Abs(path)先标准化 - 大文件别一次性读进内存（
os.ReadFile）——改用os.Open+io.Copy流式压缩，否则 OOM - 若需精确对比，原始文件大小用
info.Size()（来自os.Stat），而非len(data)，避免读取截断误差
浮点精度与显示控制
压缩比常以小数点后两位显示（如 2.45），但直接用 fmt.Printf("%.2f", ratio) 在边界值（如 1.999）会四舍五入成 2.00，掩盖实际压缩效果。更稳妥的是先乘 100、转整、再除 100.0，或用 math.Round 控制。
- 推荐计算方式：
ratio := float64(len(src)) / float64(compressedSize)，然后math.Round(ratio*100) / 100 - 当
compressedSize == 0（极端异常）必须提前判断，否则除零 panic - 输出建议带单位说明，例如
fmt.Printf("ratio: %.2f (orig: %d B → gz: %d B)\n", ratio, len(src), compressedSize)
压缩比本身不解决性能问题，但它暴露的是数据冗余程度。同一个算法在不同数据上比值差异可能极大，所以别只跑一次样本就下结论——尤其是日志、JSON、纯文本这类结构化数据，压缩前先看是否有重复字段或未压缩的 base64 内容，那才是真正的优化入口。
