gzip 压缩级别影响 CPU 与响应体大小的取舍

Go 服务开启 gzip 后，压缩级别并不是越高越好。级别越高，通常越愿意消耗 CPU 去寻找更小的输出；级别较低则更快结束，但响应体可能更大。真正要比较的是同一份业务数据在不同级别下的压缩耗时、输出字节数和端到端延迟。

一个实用的起点是：交互接口优先考虑 gzip.BestSpeed 或接近默认级别的配置，带宽明显紧张且内容高度可压缩时再评估更高级别。不要直接把 BestCompression 写成全站默认值，先用真实响应样本测量。

官方文档：https://pkg.go.dev/compress/gzip

压缩级别到底改变了什么

compress/gzip 提供 NewWriterLevel，允许传入 DefaultCompression、NoCompression、HuffmanOnly，或者 BestSpeed 到 BestCompression 之间的整数级别。级别参数控制的是压缩器寻找重复模式的投入程度，不是响应内容的语义，也不会改变解压端得到的数据。

因此要同时看三组指标：

• 压缩 CPU 时间：请求线程或压缩 worker 花在编码上的时间。
• 压缩后字节数：网络传输和带宽成本的近似指标。
• 端到端延迟：包含等待压缩、写入网络和客户端接收的总时间。

当响应很小、内容已经压缩过，或者 CPU 比带宽更紧张时，高级别带来的字节数收益可能抵不过额外的计算时间。相反，重复字段很多的 JSON、HTML 和文本通常有更大的压缩空间，但最终仍要以业务样本为准。

先用同一份输入比较级别

不要只看某一次请求的平均耗时。准备一组代表性响应，至少覆盖短 JSON、列表 JSON、HTML 文本和接近压缩格式的数据；然后分别测量多个级别。下面的最小示例只负责把同一份数据交给不同压缩器，并统计编码耗时和输出字节数。

package main

import (
	"bytes"
	"compress/gzip"
	"fmt"
	"time"
)

// compressOnce 用同一份输入比较一个 gzip 级别的耗时与输出大小。
func compressOnce(input []byte, level int) (time.Duration, int, error) {
	var out bytes.Buffer
	start := time.Now()

	// NewWriterLevel 会拒绝无效级别；生产配置不要忽略这个错误。
	zw, err := gzip.NewWriterLevel(&out, level)
	if err != nil {
		return 0, 0, err
	}
	if _, err := zw.Write(input); err != nil {
		// Close 负责收尾，但写入已经失败时仍然返回原始错误。
		_ = zw.Close()
		return 0, 0, err
	}
	// gzip 数据可能仍在缓冲区，必须 Close 后再读取最终长度。
	if err := zw.Close(); err != nil {
		return 0, 0, err
	}

	return time.Since(start), out.Len(), nil
}

func main() {
	// 重复字段更接近接口 JSON，便于观察级别差异；不要把这个结果当成线上固定比例。
	input := bytes.Repeat([]byte(`{"status":"ok","message":"gopher","items":[1,2,3,4]}`), 4000)
	levels := []int{gzip.BestSpeed, gzip.DefaultCompression, gzip.BestCompression}

	for _, level := range levels {
		elapsed, size, err := compressOnce(input, level)
		if err != nil {
			fmt.Printf("level=%d error=%v\n", level, err)
			continue
		}
		fmt.Printf("level=%d elapsed=%s compressed_bytes=%d\n", level, elapsed, size)
	}
}

这个程序的输出只用于建立比较框架。实际决策还要重复多轮，避免首次分配、调度和输入缓存让结果失真。可以记录 p50、p95 压缩耗时以及平均压缩后字节数，再和接口的超时预算、CPU 使用率、出口带宽一起看。

按业务目标选择默认级别

可以把选择过程简化成一个检查表，而不是给所有接口硬编码同一个答案：

表中的“起始选择”不是规范答案。级别越高，收益通常会递减；如果把高级别带来的流量节省换算成 CPU 成本后不划算，就应退回较低级别。短响应也要谨慎，gzip 头部和压缩器处理本身可能让结果不如直接发送。

HTTP Handler 中正确设置 gzip

HTTP 场景要先确认客户端声明支持 gzip，再设置 Content-Encoding: gzip。如果服务根据请求头选择了不同表示，还应设置 Vary: Accept-Encoding，让缓存知道编码方式属于缓存键的一部分。下面的示例把压缩级别作为配置传入，并把 Writer 的关闭动作放在所有写入之后。

package main

import (
	"compress/gzip"
	"net/http"
	"strings"
)

func gzipHandler(level int, next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		// 只在客户端明确声明 gzip 时压缩，避免发送方无法解码的响应。
		if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") {
			next.ServeHTTP(w, r)
			return
		}

		zw, err := gzip.NewWriterLevel(w, level)
		if err != nil {
			// 配置错误应在启动阶段发现；请求阶段只保留安全的降级路径。
			next.ServeHTTP(w, r)
			return
		}
		defer zw.Close()

		// 头部必须在第一次写入前设置，否则状态码和头部可能已经发出。
		w.Header().Set("Content-Encoding", "gzip")
		w.Header().Add("Vary", "Accept-Encoding")
		// 交给下一个 Handler 写入，gzip.Writer 会把内容转成压缩字节。
		next.ServeHTTP( gzipResponseWriter{ResponseWriter: w, Writer: zw}, r)
	})
}

type gzipResponseWriter struct {
	http.ResponseWriter
	*gzip.Writer
}

func (w gzipResponseWriter) Write(p []byte) (int, error) {
	// 覆盖 Write，确保业务 Handler 写到 gzip.Writer 而不是原始连接。
	return w.Writer.Write(p)
}

上面的示例展示了关键关系，但生产实现还应处理接口版本、状态码、Flush 和已经设置的 Content-Length。如果包装器没有正确转发 http.Flusher 等接口，流式响应可能出现行为变化；更稳妥的做法是使用经过审查的响应包装器，并为压缩和不压缩两条路径分别写测试。

Close、Flush 和 Reset 不能混为一谈

gzip.Writer.Write 写入的是压缩器，压缩字节不一定马上落到底层 Writer。官方文档明确要求在完成写入后调用 Close，它会刷新未写出的数据并写入 gzip 尾部；只读取底层缓冲区而不关闭，得到的长度可能不完整。

Flush 适合需要尽快把已有压缩数据交给网络的流式协议，但它会牺牲部分压缩连续性，不能代替最终的 Close。如果响应是 SSE 或长连接，必须额外确认 ResponseWriter 是否支持刷新，以及客户端能否按预期处理压缩流。

Reset 用于让一个 Writer 改为向新的底层 Writer 输出。它可以减少重复创建压缩器的开销，但复用对象时要保证上一次已经 Close，并且不要把上一个请求的状态、头部或错误带到下一个请求。对象池优化只有在压测证明分配成本明显时才值得加入。

最容易出现的几个误区

• 只看压缩后大小：小了几 KB，却忽略每个请求增加的 CPU 和排队时间。
• 把 Content-Length 原样保留：压缩后长度已经变化，流式压缩通常应让传输层自行处理长度。
• 没有检查 Accept-Encoding：客户端不支持 gzip 时仍发送压缩数据，会造成解码失败。
• 先写响应再设置头部：HTTP 头部一旦发出，再补 Content-Encoding 已经太晚。
• 压缩所有内容：图片、视频和压缩包通常已经编码过，继续 gzip 只增加 CPU。
• 把演示程序比例当成结论：重复字符串的收益不能代表真实业务，必须换成线上脱敏样本。

上线前的压缩级别检查清单

1. 按响应类型准备短 JSON、长 JSON、HTML 和已压缩内容样本。
2. 固定输入与并发量，分别测量 BestSpeed、默认级别和候选高级别。
3. 记录 p50/p95 延迟、CPU 使用率、压缩后字节数和错误率，不只记录平均值。
4. 确认只对声明支持 gzip 的请求发送压缩响应，并设置 Vary: Accept-Encoding。
5. 确认关闭 Writer、处理 Flush、移除不再准确的长度信息，并覆盖异常写入路径。
6. 先灰度一个接口，再根据带宽和 CPU 的实际变化收口全局默认级别。

归纳起来，gzip 级别是资源分配旋钮：用更高 CPU 换更小的响应体。低延迟接口从较低或默认级别开始，带宽确实成为瓶颈时再提高级别，并用同一套真实样本持续比较。这样得到的配置，才是对当前服务有效的取舍，而不是对某个压缩级别的盲目偏好。

相关问题

gzip.DefaultCompression 是固定的最佳选择吗？

不是。它只是一个合理的起点，最终仍要结合响应内容、CPU 预算和带宽成本测量。

为什么 gzip.Close 必须调用？

Writer 可能仍有缓冲数据，Close 会把未写出的压缩内容刷新到底层 Writer，并写入 gzip 尾部。

所有 JSON 都应该压缩吗？

不应该。要考虑响应大小、客户端协商、CPU 负载和缓存策略；很小的 JSON 或已经压缩的载荷可能没有收益。

提高压缩级别会改变解压结果吗？

不会。合法级别只改变压缩过程的资源投入和编码结果大小，解压后的业务数据应保持一致。