Go语言如何做接口返回压缩_Golang gzip中间件响应压缩方案-Golang-PHP中文网

go http 响应默认不压缩，gzip.handler 必须置于最外层且满足状态码2xx/3xx、content-length>1024或未知、content-type可压缩三条件才生效；漏close()或错放中间件会导致解压失败。

go语言如何做接口返回压缩_golang gzip中间件响应压缩方案

Go 默认不压缩 HTTP 响应体，哪怕客户端发来 Accept-Encoding: gzip，服务端也原样返回明文。直接上 gzip.Handler 是最稳的生产方案，但位置错、类型漏、状态码卡住，压缩就静默失效。

用标准库 `gzip.Handler` 必须包在最外层

它需要完整接管 ResponseWriter 的 Write 和 WriteHeader 调用。一旦被日志、CORS、认证等中间件包在里面，底层 writer 就已被封装，gzip.Handler 就压不到响应体，却可能误设 Content-Encoding: gzip 头——浏览器解压失败，报 ERR_CONTENT_DECODING_FAILED。

正确写法：

http.ListenAndServe(":8080", gzip.Handler(myMux))

错误写法（压缩失效）：

http.ListenAndServe(":8080", loggingMiddleware(gzip.Handler(myMux)))

静态文件服务（如 http.FileServer）也得包进去，否则 .js/.css 不压缩
若用 chi.Router 或 gin.Engine，确保 gzip.Handler 是最终 http.Handler 的包装者，不是路由内部中间件
它不修改原始 ResponseWriter 的 Content-Length，而是删掉该 header，改用 Transfer-Encoding: chunked

`gzip.Handler` 不压缩的三种典型情况

它不是“有 gzip 请求头就压”，而是硬性满足三个条件才触发：

响应状态码必须是 2xx 或 3xx（4xx/5xx 默认跳过，避免暴露错误细节）
Content-Length 未知，或已知且 > 1024 字节（小响应不压，压缩收益低还耗 CPU）
Content-Type 属于可压缩 MIME 类型，如 text/html、application/json、text/css；而 image/png、application/octet-stream 这类本身已压缩的类型会被跳过

调试时最直接的方法：curl -I -H "Accept-Encoding: gzip" http://localhost:8080/，看响应头有没有 Content-Encoding: gzip。没有？检查是否漏设 Content-Type（比如返回 JSON 却写了 text/plain）。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

手动用 `gzip.Writer` 时，`Close()` 绝对不能省

gzip.Writer 的 Write() 只把数据送进缓冲区，真正的压缩、CRC32 校验和、原始长度（ISIZE）都只在 Close() 时写入流末尾。漏掉它，解压端必然报 gzip: invalid checksum 或 unexpected EOF。

常见错误写法：

gz := gzip.NewWriter(w)
io.Copy(gz, body) // ❌ 缺少 Close()

正确写法（必须显式调用）：

gz := gzip.NewWriter(w)
io.Copy(gz, body)
gz.Close() // ✅ 关键一步，确保尾部元数据写出

gz.Flush() 不能替代 Close()，它不写 CRC/ISIZE
若后续要把压缩结果存 Redis（如 HSET cache:key body），bytes.Buffer.Bytes() 返回的 []byte 必须来自已 Close() 的 gzip.Writer，否则 redis-cli --raw get key | gunzip 会失败
压缩级别可用 gzip.BestSpeed（1）或 gzip.DefaultCompression（-1），别盲目设 BestCompression（9），CPU 开销会上升明显