Gin默认不自动压缩响应，因gin.Default()未集成Gzip中间件，需引入gin-contrib/gzip并调用r.Use(gzip.Gzip(gzip.DefaultCompression))启用；手动实现易出错，验证须确认请求头、响应头及真实压缩体。
为什么Gin默认不自动压缩响应
Gin本身不内置Gzip中间件，gin.Default()只加了日志和恢复中间件，Content-Encoding: gzip不会自动出现。即使客户端发了Accept-Encoding: gzip，服务端也照常返回明文，浏览器或客户端收不到压缩数据。
用gin-contrib/gzip中间件最稳妥
官方推荐的gin-contrib/gzip封装了http.ResponseWriter的包装逻辑，支持按状态码、MIME类型、最小响应体长度过滤，避免小响应被无意义压缩。
- 安装：
go get github.com/gin-contrib/gzip - 启用（全局）：
r.Use(gzip.Gzip(gzip.DefaultCompression)) - 启用（局部路由）：
r.GET("/api/data", gzip.Gzip(gzip.DefaultCompression), handler) - 可选配置：用
gzip.Gzip(gzip.BestSpeed)或gzip.BestCompression控制压缩级别；加gzip.WithExcludedPaths([]string{"/health"})跳过健康检查等路径
手动调用gzip.Writer容易出错
自己写gzip.NewWriter再包装c.Writer看似灵活，但极易漏掉Close()、误写Header()顺序、或在panic恢复时丢弃压缩流——结果是响应头写了Content-Encoding: gzip，但body是明文，客户端解压失败报ERR_CONTENT_DECODING_FAILED。
- 必须在
Write()后显式调用gz.Close()，否则部分数据可能滞留在缓冲区 - 不能在
c.Header()之前调用gz.Write()，否则Content-Length计算错误 - 如果handler里用了
c.Abort()或发生panic，自定义gzip writer大概率没机会Close()，导致连接卡住或响应损坏
验证是否真生效的三个关键点
光看响应头不够，得确认三件事：客户端请求带Accept-Encoding: gzip、服务端返回Content-Encoding: gzip、且响应体确实是二进制压缩流（不是base64或乱码）。
立即学习“go语言免费学习笔记（深入）”；
- 用
curl -H "Accept-Encoding: gzip" -v http://localhost:8080/api/data看后是否有<code> - 用
curl -H "Accept-Encoding: gzip" http://localhost:8080/api/data | gunzip -t测试能否无错解压 - 注意浏览器开发者工具Network面板有时会自动解压显示，要切到“Raw”或“Headers”页签看原始响应头和size，对比未压缩时的body大小
压缩效果取决于响应体大小，小于1KB的内容开启gzip反而可能变大，gin-contrib/gzip默认只压缩≥1KB的数据，这个阈值可以调，但没必要为极小响应牺牲CPU。
