Go png.Encoder 怎样选择 CompressionLevel 平衡大小和速度

Go 的 png.Encoder.CompressionLevel 不是画质开关，而是 PNG 编码过程中 zlib 压缩强度的选择。通常先从零值 DefaultCompression 开始；接口实时生成图片更关注响应时间时可以尝试 BestSpeed；静态资源或归档更在意文件体积时再比较 BestCompression。最终选择不能只看一个样本，应该用真实图片批量记录编码耗时和输出字节数。

如果没有明确的体积或延迟目标，保留默认级别最稳妥；只有在测量证明收益足够覆盖额外 CPU 成本时，才切换到最快或最强压缩。

• 默认起点：DefaultCompression，也是 Encoder 零值的语义。
• 延迟优先：BestSpeed，适合实时接口或大量临时缩略图的候选方案。
• 体积优先：BestCompression，适合生成后会被反复分发的静态资源。
• 排查基线：NoCompression，用于对比压缩阶段的成本，不代表所有图片都会更快。

四个 CompressionLevel 到底改变了什么

image/png 提供四个预置常量：默认压缩、无压缩、最佳速度和最佳压缩。Encoder.Encode 会把它们转换成内部 zlib 级别，再写入 PNG 的 IDAT 数据块；PNG 的颜色类型、行过滤和文件头仍由输入图像及编码器处理。也就是说，选择级别主要改变压缩数据的计算量与结果体积，不应被当成降低分辨率或减少颜色的有损处理。

package main

import "image/png"

func encoderForAPI() png.Encoder {
	return png.Encoder{
		// 在线生成先使用最快级别，最终是否采用要用真实图片测量。
		CompressionLevel: png.BestSpeed,
	}
}

为什么文件更小通常也意味着编码更慢

PNG 本身是无损格式，压缩级别不会让解码后的像素主动变模糊。编码器会把每行像素转换成字节，再交给 zlib 写入 IDAT；压缩强度越高，通常需要更多计算来寻找更紧凑的表示，因此可能减少输出字节数，也可能增加 CPU 时间。图片内容会显著影响结果：大面积纯色、重复纹理和带透明通道的图像，体积变化不一定与另一张照片相同。

因此不要把“最佳压缩”理解为固定能省下某个百分比，也不要把“最佳速度”理解为一定得到最小延迟。Go 文档还说明，Encoder 零值会映射到 zlib 的默认压缩级别；未识别的级别也会回到默认映射。正数值目前只是预留的数值级别语义，不能当成已实现的 1 到 9 档接口。

按工作负载选一个可解释的起点

实时 HTTP 响应一般先比较 DefaultCompression 与 BestSpeed，重点看 p95/p99 延迟和 CPU，而不是只看单张文件大小。离线生成静态资源则可以比较默认级别与 BestCompression，把生成耗时和后续存储、传输节省放到同一张成本表里。需要定位问题时，用 NoCompression 作为参照，能帮助判断时间主要花在像素转换、行过滤、zlib 压缩还是输出写入。

一个简单的编码封装可以把选择集中在调用边界，避免业务代码散落 magic number：

func encodePNG(img image.Image, level png.CompressionLevel) ([]byte, error) {
	var buf bytes.Buffer
	enc := png.Encoder{CompressionLevel: level}
	// 把错误原样返回，调用方才能区分编码失败和后续写入失败。
	if err := enc.Encode(&buf, img); err != nil {
		return nil, err
	}
	return buf.Bytes(), nil
}

这段代码没有改变图片尺寸或颜色模型；它只把压缩级别作为一次编码请求的参数。若输出要直接写文件或网络响应，应继续检查目标 io.Writer 的错误，不要只依赖内存缓冲区的示例。

怎样做一次有意义的大小与速度比较

比较时固定输入图片、尺寸、颜色模型、输出介质和 Go 运行环境；每个级别重复多轮，丢弃首次预热或单独记录它。每轮至少保存编码耗时、输出字节数和错误状态，最后按图片类型分别汇总。不要拿一张纯色图的结论去替代照片、透明图或业务实际缩略图的结论。

func measure(img image.Image, level png.CompressionLevel) (time.Duration, int, error) {
	start := time.Now()
	data, err := encodePNG(img, level)
	// 先返回错误，避免把失败样本误记成零字节或极快结果。
	if err != nil {
		return 0, 0, err
	}
	return time.Since(start), len(data), nil
}

如果结果差异很小，优先选择更容易解释和维护的默认级别；如果 BestSpeed 明显降低延迟但只增加可接受的体积，就把它作为在线路径的候选。如果 BestCompression 节省的空间能抵消生成阶段增加的 CPU 和等待时间，再把它用于离线产物。

迁移时要留意的边界

从 png.Encode 改成 Encoder.Encode 时，最小变化是显式创建 png.Encoder 并设置级别。不要在测试中依赖 PNG 的精确字节序列，因为同一输入的具体输出字节并不属于 Go 兼容性承诺；测试应优先解码后比较图像语义，或比较文件大小、耗时等业务指标。BufferPool 只负责复用编码临时缓冲区，它可以降低重复编码的分配压力，但不会把 BestSpeed 变成另一种压缩级别。

常见问题

CompressionLevel 设置为 0 是不是关闭压缩？

不是。0 对应 DefaultCompression，也就是编码器零值采用的默认压缩级别；要做无压缩基线应明确使用 NoCompression。

BestCompression 一定比 DefaultCompression 小吗？

不能脱离具体图片和实现版本下定论。它表示更强的压缩取向，应该用同一批真实输入测量体积和耗时，再决定是否值得。

可以直接传 1 到 9 选择 zlib 档位吗？

不要这样设计业务契约。当前正数值只是预留语义，未实现的值会按源码映射回默认级别；代码应使用公开的四个预置常量。