最直接测压缩比应使用 compress 接口：写入原始数据→关闭 writer→比较源长度与目标 buffer 长度；必须调用 close() 触发帧尾写入和校验和计算，否则结果偏小、不可复现。
用 compress 接口测压缩比最直接
Go 里没有内置 LZ4 支持，必须用第三方库（如 github.com/pierrec/lz4/v4），但它的 Writer 和 Reader 接口行为和标准库 compress/gzip 一致，所以测压缩比的逻辑完全通用：写入原始数据 → 关闭 writer → 比较源长度与目标 buffer 长度。
关键点是不能只看 Write() 返回值，它只反映已写入缓冲区的字节数，不是最终压缩结果；必须调用 Close() 触发帧尾写入和校验和计算，否则结果偏小、不可复现。
-
NewWriter()返回的*lz4.Writer必须配对调用Close()，否则压缩流不完整 - 不要用
WriteString()直接写入大字符串，避免隐式 UTF-8 转换开销干扰基准 - 原始数据建议用
[]byte构造，避免重复string→[]byte转换
lz4.CompressBlock 测的是块级压缩率，不是文件级
如果你调用的是底层块压缩函数（如 lz4.CompressBlock 或 lz4.CompressBlockHC），得到的只是单块压缩结果，不含帧头、校验和、块分隔等开销。实际文件压缩（比如用 lz4c 命令生成的 .lz4 文件）会多出约 12–20 字节/块的元数据，尤其在小数据或分块多时差异明显。
- 块压缩适合嵌入协议或内存中短数据压缩，不反映磁盘文件大小
-
CompressBlock不处理边界对齐，输入长度超过lz4.MaxBlockSize（默认 4MB）会 panic - 若要模拟 CLI 行为，应走
NewWriter+io.Copy流式路径，而非手动分块
测试时必须控制数据特征和压缩等级
LZ4 的压缩比高度依赖输入数据的重复性与模式。用全零、递增字节、随机字节三类数据测出的结果可能差 3 倍以上；同样，-1（快速）和 -9（高压缩）等级下，同一份日志文件的压缩比可能从 35% 降到 25%，但耗时翻 5 倍。
- 真实业务数据优先：比如取一段生产日志、JSON 日志切片、Protobuf 序列化字节
- Go 中设置等级需用
WriterOption，例如lz4.WithLevel(lz4.Level9)，不是环境变量 - 避免用
generateTestData(1024*1024*40)这类线性递增数据，它有强周期性，会高估 LZ4 表现
别忽略解压后校验环节
压缩比数字好看没用，如果解压失败或内容错位，说明你漏了帧格式兼容性检查。LZ4 v1.10+ 默认启用 Frame 格式，而旧版工具（如某些嵌入式 lz4 解压器）可能只支持 legacy block 格式。
- 用
lz4.NewReader解压后，务必比对sha256.Sum256或bytes.Equal原始与解压后字节 - 如果测试中出现
LZ4F_isError或invalid frame descriptor错误，大概率是用了NewWriterLegacy却拿标准NewReader去读 - 命令行验证可作为交叉参考：
echo -n "hello" | lz4 | lz4 -d输出是否一致
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
