compressflate调整压缩速度

用 Go 的 compress/flate 调整压缩速度，入口只有一个：创建 Writer 时传入 level。它不是运行中的滑块，也没有单独的“速度设置”方法。一般把 BestSpeed 用在延迟敏感的在线响应，把 DefaultCompression 作为通用起点；需要更小文件时再评估 BestCompression，输入已经经过 LZ 类压缩时才考虑 HuffmanOnly。

compress/flate 调速的核心是 level

flate.NewWriter 的第二个参数决定匹配搜索与编码策略。常用等级可以这样理解：

此外，NoCompression（0）只保留 DEFLATE 所需的帧结构，适合协议格式需要统一而不想再做压缩的场景。合法范围是 -2 到 9，传入其他值应当直接处理构造错误。

用 Close 完成一次可复用的压缩写出

最小实现不复杂，但有两个容易漏掉的点：NewWriter 可能返回错误，Close 也可能在最后写出时失败。下面的函数把这两个边界都保留下来：

package main

import (
	"bytes"
	"compress/flate"
)

func compressBytes(data []byte, level int) ([]byte, error) {
	var dst bytes.Buffer
	// level 控制压缩策略；先把构造错误返回给调用方。
	writer, err := flate.NewWriter(&dst, level)
	if err != nil {
		return nil, err
	}
	// Write 只负责接收输入，底层写入失败也不能忽略。
	if _, err = writer.Write(data); err != nil {
		_ = writer.Close() // 发生错误时尽力结束资源，再返回原始错误。
		return nil, err
	}
	// Close 会完成压缩流的收尾，不能用 Flush 代替最终关闭。
	if err = writer.Close(); err != nil {
		return nil, err
	}
	return dst.Bytes(), nil
}

如果是持续输出的流，Flush 可以把当前数据尽快推给下游，但频繁 Flush 会减少跨块匹配机会并增加输出开销。文件或完整消息通常等全部数据写入后直接 Close 更合适。

速度选择要用数据而不是等级名称

压缩等级不是“越高越专业”。短 JSON、随机数据和重复文本的收益曲线可能完全不同；在生产环境至少按同一批输入测三项：压缩耗时、输出字节数、调用方看到的 p95 或 p99 延迟。

在线接口可以从 BestSpeed 和 DefaultCompression 做 A/B 基准；归档任务则比较 DefaultCompression 与 BestCompression 的存储节省是否抵得过 CPU 时间。若输入已经是 Snappy、LZ4 一类结果，普通 LZ 匹配空间很小，HuffmanOnly 才值得单独测试，不能因为名字里有“Only”就默认更快且更小。

高频批处理可以复用 Writer，减少内部状态反复分配：

func compressBatches(batches [][]byte, level int) ([][]byte, error) {
	var dst bytes.Buffer
	// Writer 只创建一次；每轮 Reset 到同一个输出缓冲区。
	writer, err := flate.NewWriter(&dst, level)
	if err != nil {
		return nil, err
	}
	results := make([][]byte, 0, len(batches))
	for _, batch := range batches {
		dst.Reset()
		writer.Reset(&dst)
		// 每轮 Close 后再由下一轮 Reset 重新开始一个压缩流。
		if _, err = writer.Write(batch); err != nil {
			return nil, err
		}
		if err = writer.Close(); err != nil {
			return nil, err
		}
		results = append(results, append([]byte(nil), dst.Bytes()...))
	}
	return results, nil
}

这里复制了 dst.Bytes()，是因为下一轮 Reset 会继续复用缓冲区；如果调用方允许立即消费结果，也可以改成边写边发送，避免保存所有切片。

几个容易误判的边界

• 不要比较精确字节序列。官方文档没有保证不同 Go 版本写出的精确 DEFLATE 字节一致，测试应优先验证可解压、大小和业务结果。
• 不要把 Flush 当成提交。它是流式推进手段；最终完整输出仍要检查 Close。
• 不要只测一条样本。同一等级对重复文本和随机数据的压缩率差异很大，基准应覆盖真实输入分布。

相关问题

BestSpeed 一定比 DefaultCompression 快吗？

通常更偏向速度，但实际耗时还受输入内容、底层 Writer 和调度影响，应该用业务样本测量，而不是把常量名当作硬性 SLA。

为什么只调用 Write 也能拿到部分输出？

Writer 可能已经向下游写出部分数据，但压缩流还未完成。需要完整独立结果时必须调用并检查 Close。

压缩等级可以在同一个 Writer 上动态修改吗？

不能直接修改已创建 Writer 的 level。要切换等级，应结束当前 Writer，再用新等级创建另一个 Writer；高频同等级批处理才适合用 Reset 复用。