压缩比例由原始数据与压缩后字节长度比值决定，需手动计算float64(len(input))/float64(len(compressed))，调用w.flush()确保完整写出，避免整除错误和缓冲区未刷新导致失真。
zlib.CompressLevel 不影响压缩比例计算逻辑
压缩比例不是由 zlib.CompressLevel 决定的，而是原始数据与压缩后字节长度的比值。Go 的 compress/zlib 包本身不提供“预估压缩率”或“内置比例计算”函数，必须手动对比输入和输出长度。
注意：压缩比例高度依赖数据内容——纯文本、日志、JSON 通常能压到 30%–50%，而已压缩图像、加密数据或随机字节几乎不压缩（甚至略膨胀）。
- 必须用
len(input)和len(compressedData)直接相除，别用文件大小或io.Copy返回值代替原始长度 - 如果输入是流（如
io.Reader），需先读入内存或用io.TeeReader计数，否则无法获知原始字节数 - 压缩前若做
bytes.TrimSpace或去重等预处理，会改变比例，但那是业务逻辑，不是 zlib 行为
正确获取压缩后字节长度：别漏掉 w.Close() 或 w.Flush()
使用 zlib.NewWriter 时，不调用 Close()（或 Flush()）会导致缓冲区未写出，buf.Bytes() 可能只包含部分数据，压缩比例严重失真。
常见错误现象：len(buf.Bytes()) 比预期小很多，算出来“压缩率 99%”，实际解压失败或数据不全。
-
zlib.Writer没有Close()方法，只有Flush()—— 必须显式调用，否则 Adler-32 校验尾部可能缺失（虽不影响多数解压器，但协议互通时可能被拒绝） - 若用
zlib.NewWriterLevel(&buf, zlib.BestCompression)，同样要Flush()才能确保全部写出 - 推荐写法：
w.Write(data); w.Flush(); compressed := buf.Bytes()
避免浮点精度陷阱：用 float64 而非 int 做除法
直接写 len(input) / len(compressed) 是整数除法，结果恒为 1（当 input > compressed 时）。必须至少一方转为浮点类型。
示例代码片段：
input := []byte("some log data...")
var buf bytes.Buffer
w := zlib.NewWriter(&buf)
w.Write(input)
w.Flush()
compressed := buf.Bytes()
ratio := float64(len(input)) / float64(len(compressed))
fmt.Printf("Compression ratio: %.2f×\n", ratio) // 输出类似：3.24×
- 不要用
int运算后转 float ——float64(len(input)/len(compressed))错误！整除已丢精度 - 如果压缩后长度为 0（极罕见，如空输入+特殊级别），需加零长判断，否则 panic
- 比例大于 1 表示压缩有效；小于 1 表示膨胀（例如加密二进制、PNG 文件再 zlib 压缩）
并发压缩时比例计算要按 goroutine 独立进行
多个 goroutine 并行压缩不同数据块时，每个块的压缩比例可能差异极大——一段全是空格的日志 vs 一段 base64 编码的图片。
不能把所有输入长度求和、再除以所有输出长度求和，那样掩盖了数据局部特性，对调优无意义。
- 每个任务应单独记录
len(input)和len(compressed)，再汇总统计中位数/分位数，而非简单平均 - 若某次压缩后长度异常（如 > 输入长度 110%），建议打 warning 日志，可能是数据不可压缩或缓冲区复用出错
- 注意：zlib 自身每实例仅占约 256 KB 内存，但你的
input和compressed切片才是内存大头——比例计算本身不耗资源，但误判会导致缓冲区分配策略失效
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
