Go的http.Server默认不启用gzip压缩，因遵循“显式优于隐式”原则，需开发者按需控制协商、开销与Header设置；推荐用中间件包装ResponseWriter，检查Accept-Encoding、设Vary头、延迟写Header、避免小响应和已压缩类型。
直接用 gzip 压缩 HTTP 响应体是有效的，但 Go 标准库的 http.Server 默认不启用压缩；手动集成 gzip.Writer 容易出错，尤其在错误处理、Header 设置和 Body 写入顺序上。
为什么 net/http 默认不压缩响应
Go 的 http.Server 设计原则是“显式优于隐式”——压缩涉及额外 CPU 开销、Content-Length 变更、Transfer-Encoding 切换，且需协商 Accept-Encoding，标准库选择交由开发者按需控制。
- 不检查客户端是否支持
gzip就硬压，会导致部分老客户端（如某些嵌入式设备）解析失败 - 未重置
Content-Length或遗漏Vary: Accept-Encoding头，可能引发 CDN 缓存污染 - 对已设置
Content-Length的响应再套gzip.Writer，会触发http: superfluous response.WriteHeader call错误
用 http.ResponseWriter 包装器实现安全压缩
推荐使用中间件方式包装 http.ResponseWriter，而非直接替换 Write 方法。关键点在于：只对支持 gzip 的请求生效、自动设置 Vary、延迟写入 Header 直到真正需要压缩时。
- 先读取请求头
r.Header.Get("Accept-Encoding")，检查是否含gzip - 若支持，用
gzip.NewWriter(w)包装响应体，并在WriteHeader时才写入Content-Encoding: gzip - 务必调用
gzw.Close()（通常在http.Handler返回前），否则数据可能未 flush - 避免对
204、304等无 body 的状态码启用压缩
示例片段：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
func gzipMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") {
next.ServeHTTP(w, r)
return
}
gz := gzip.NewWriter(w)
defer gz.Close()
w = &gzipResponseWriter{Writer: gz, ResponseWriter: w}
next.ServeHTTP(w, r)
})
}
type gzipResponseWriter struct {
io.Writer
http.ResponseWriter
}
func (w *gzipResponseWriter) Write(b []byte) (int, error) {
return w.Writer.Write(b)
}
func (w *gzipResponseWriter) WriteHeader(code int) {
w.ResponseWriter.Header().Set("Content-Encoding", "gzip")
w.ResponseWriter.Header().Set("Vary", "Accept-Encoding")
w.ResponseWriter.WriteHeader(code)
}
注意 Content-Type 和小响应体的压缩开销
不是所有响应都适合压缩。文本类（text/html、application/json）收益明显；而图片、视频、已压缩格式（application/octet-stream）再压反而增大体积或浪费 CPU。
- 建议对
Content-Type包含text/、application/json、application/javascript的响应启用压缩 - 可设最小阈值（如
1024字节），小于该值跳过压缩——避免 200B 的 JSON 被 gzip 后变成 280B - Go 1.19+ 中
gzip.BestSpeed（1）比默认DefaultCompression（6）更适合高并发 API，压缩耗时降低约 40%，体积仅多 3–5%
调试时如何确认压缩生效
别只看 Content-Encoding 响应头是否出现——它可能被设了但实际没压缩（比如 WriteHeader 调用太早导致 gzip.Writer 未介入）。最可靠的方式是抓包对比原始与压缩后字节数。
- 用
curl -H "Accept-Encoding: gzip" -v http://localhost:8080/api，观察< HTTP/1.1 200 OK后是否有Content-Encoding: gzip和Content-Length显著变小 - 若返回
Content-Length比未压缩时还大，说明响应体太小或类型不适合压缩 - 浏览器开发者工具 Network 标签页中，Size 列显示 “
xx B (gzip)” 才算真正生效
压缩逻辑一旦嵌入中间件链，就容易被多个中间件重复包装（比如日志中间件也包装了 ResponseWriter），最终导致 gzip.Writer 写入 panic。上线前务必做压力测试并检查 error log 中是否出现 write tcp: broken pipe 或 io: read/write on closed pipe 类错误。
