压缩比需手动计算原始与压缩后字节长度之比；len(slice)仅返回元素数，[]byte才等于字节数，其他类型须先序列化为[]byte再压缩，且序列化方式影响压缩效果。
不能直接估算切片的压缩比——因为“压缩比”不是切片自身的属性，而是你对切片内容做特定压缩（如 gzip）前后字节长度的比值。Go 本身不提供内置压缩比计算函数，必须手动比较原始数据长度与压缩后长度。
为什么 len(slice) ≠ 压缩前真实输入长度？
切片的 len() 返回的是元素个数，不是字节长度；只有 []byte 类型才满足“元素数 == 字节数”。其他类型如 []int64、[]string 必须先序列化（如用 encoding/json 或 gob）才能压缩，而序列化本身会引入额外开销（比如 JSON 的引号、逗号、转义）。
-
[]byte{1,2,3}→ 压缩前就是 3 字节，可直接用len() -
[]int64{1,2,3}→ 原始内存占 3×8 = 24 字节，但 JSON 序列化后可能是"[1,2,3]"（9 字节），gob 编码后又不同 -
[]string{"a","bb"}→ 字符串字段含 header（16 字节）+ 实际字符数据，必须遍历累加len(s[i])才得总内容字节数
压缩前必须先得到“可压缩的字节流”
对任意切片做压缩，第一步永远是把它变成 []byte。常见路径：
-
[]byte：跳过序列化，直接传给gzip.NewWriter -
struct{...}或[]T（T 非 byte）：用json.Marshal或gob.Encoder编码为[]byte，再压缩 - 注意
gob比json更紧凑（无字段名、二进制），但不可读、不跨语言；json可读但膨胀明显
示例（[]int → JSON → gzip）：
立即学习“go语言免费学习笔记（深入）”；
data := []int{1, 2, 3, 4, 5}
b, _ := json.Marshal(data) // b = []byte("[1,2,3,4,5]"), len=13
var buf bytes.Buffer
gz := gzip.NewWriter(&buf)
gz.Write(b)
gz.Close() // 必须！否则 buf.Bytes() 不完整
compressed := buf.Bytes()
ratio := float64(len(compressed)) / float64(len(b))
压缩比受数据特征和切片容量影响极大
相同逻辑数据，不同切片构造方式可能导致压缩结果差异：
- 底层数组有“脏数据”：比如
s := make([]byte, 1000, 2000)，只写入前 100 字节，但cap()是 2000 —— 若误把整个底层数组（2000 字节）当成输入去压缩，压缩比会严重失真 - 字符串切片中混杂长空格或重复前缀：这类数据 gzip 效果好；随机加密数据则几乎不压缩（压缩后可能略大）
- 小切片（
真正实用的压缩比估算，必须基于 len(序列化后字节) 和 len(压缩后字节)，且确保序列化输出是紧凑、无冗余的。别跳过 Close()，也别用 Flush() 替代它——这是最常被忽略、导致压缩比算错的根本原因。
