真实压缩比例必须通过实际调用zstd.encodeall等压缩方法获得，再用len(original)/len(compressed)计算，不可预估；需确保输入输出均为字节切片、预分配缓冲区、避免nil导致内部分配干扰长度统计。
直接用 len(original) 除以 len(compressed) 就能算出压缩比例，但必须注意原始数据和压缩后数据都得是字节切片，且不能跳过压缩过程本身——很多人误以为调用 zstd.Encoder 的某个方法就能“预估”比例，其实不行，zstd 压缩率高度依赖内容模式、长度和压缩级别，必须实际压一次才能知道。
怎么用 zstd.EncodeAll 算一次真实压缩比例
这是最常用也最可靠的计算方式：把原始数据喂给压缩器，拿到结果后再做除法。它适合小到中等尺寸数据（比如单条日志、protobuf 消息），不建议在热路径反复调用。
-
zstd.EncodeAll是内存操作，不涉及流式缓冲或状态复用，每次调用都是干净的 - 传入的压缩级别会影响结果，比如
zstd.WithEncoderLevel(zstd.SpeedFastest)和zstd.WithEncoderLevel(zstd.BestCompression)可能差出 2–3 倍比例 - 别用
nil当输出缓冲——虽然 API 允许，但会触发内部分配，导致你无法准确获取压缩后长度；应预先分配一个足够大的[]byte，再用cap()和len()判断是否截断
示例：
original := []byte("some protobuf or json data...")
dst := make([]byte, len(original)) // 预分配，避免扩容干扰长度判断
enc, _ := zstd.NewWriter(nil, zstd.WithEncoderLevel(zstd.SpeedDefault))
compressed := enc.EncodeAll(original, dst[:0]) // 注意 dst[:0] 清空但保留底层数组
ratio := float64(len(original)) / float64(len(compressed))
fmt.Printf("压缩比例: %.2f:1\n", ratio)
流式压缩下怎么拿压缩后长度
当走 io.WriteCloser 路线（比如压缩 HTTP 响应体或写文件），Write 返回的是写入字节数，但这个数不是压缩后长度——它只是源数据长度。真正压缩后的字节是在底层 writer 写出时才确定的。
- 最简单办法：包装一个
bytes.Buffer当底层 writer，压缩完再读buf.Len() - 如果底层是文件或网络连接，没法回读，那就得用
zstd.Encoder的Write方法配合自定义io.Writer实现计数器，而不是依赖返回值 - 别在
Close()后才去查长度——有些场景（如超时中断）可能导致Close()失败，但已有部分数据写出，此时长度已不可靠
为什么不能靠 zstd.Encoder 的 Reset 或 Flush 预估比例
因为 zstd 是基于滑动窗口和多段编码的算法，Reset 只清空状态，不提供任何压缩中间结果；Flush 也不保证输出完整帧，尤其在低级别压缩下可能只输出部分 token。实测中，对同一段数据连续调用 Flush 两次，第二次几乎不产生新字节，但这不代表第一次就完成了全部压缩。
- 想批量评估不同压缩级别的效果？老老实实用循环 +
EncodeAll，别试图优化这一步 - 如果原始数据很大（>10MB），又不想全量压缩，可采样前 1MB 做测试——zstd 在局部数据特征稳定时，采样比例误差通常
- 注意：字典压缩（
zstd.WithDecoderDict/zstd.WithEncoderDict）会让比例严重依赖字典匹配程度，这种情况下必须用带字典的完整流程跑，否则结果毫无参考价值
压缩比例不是固定值，它随输入内容、压缩级别、是否启用字典、甚至 Go 运行时版本（特别是 noasm 构建时）而变。别存成常量，别硬编码阈值，每次需要时就压一次——这才是最稳的做法。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
