发布 1.0.0 版本：用于 Gin 和 net/http 的 gzip 中间件，再也不担心返回的 JSON 太大了

• 資深大佬 : airplayxcom

  已 star

• 資深大佬 : qwerthhusn

  最怕的就是没配好，程序压缩了一个，代理又解压了，完事再压缩一次

• 主 資深大佬 : nanmu42

  @qwerthhusn 对，这个问题得规避。一般是看[Content-Encoding 和 Transfer Encoding]( https://github.com/nanmu42/gzip/blob/895747f7d735b2d9ee32e8f8847377c1bc59e253/responsefilters.go#-L32-L37).

• 資深大佬 : lianyue

  我 以前也写了个

  https://github.com/otamoe/gin-compress

  gzip + br 支持 br 的

• 資深大佬 : also24

  唔… 提问一下，自己做这件事和靠 nginx 来做这件事，会有哪些差异呢？

• 資深大佬 : SingeeKing

  @also24 #5 Go 哲学之不用 nginx 转发？

• 資深大佬 : imherer

  @SingeeKing 用 Caddy 吗

• 主 資深大佬 : nanmu42

  @also24 @SingeeKing 纯粹是萝卜青菜的喜好问题，并不分孰优孰劣，就结果来说没有什么差异。有选项总比没有选项好一些。

• 資深大佬 : imherer

  @nanmu42 试用了下，还可以，已 star

  不过有个小疑问，用 postman 请求的结果是压缩了也没用吗？
  因为我发现只有浏览器访问有效果，postman 请求的话 header 里显示已压缩了，但是大小实际没变化

• 資深大佬 : zhs227

  @imherer postman 好像会自己解压 gz 的东西，方便你查看

• 資深大佬 : imherer

  @zhs227 哦……这样啊
• 主 資深大佬 : nanmu42

  @imherer 如果返回的 header 里有`content-encoding: gzip`，说明本条返回通过判定，成功被压缩了，`Content-Length`（如果有）这个时候是指压缩后的大小。

• 資深大佬 : imherer

  @nanmu42 嗯。content-encoding: gzip 是有的。 应该就是上他们说的 postman 会解压 gz 吧

• 資深大佬 : yiplee

  一直在用 chi/middleware 里面的 compress，主这个也不错

• 資深大佬 : solos

  之前不是有了 https://github.com/gin-contrib/gzip

• 主 資深大佬 : nanmu42

  @solos 对，可惜它实在不好用，甚至不可用： https://github.com/gin-contrib/gzip/issues

• 資深大佬 : Allianzcortex

  理论上是不是核心代码两行就可以搞定…

  “`
  unc CompressGZResult(w http.ResponseWriter, r *http.Request, res interface{}) {
  w.Header().Set(“Content-Type”, “application/json”)
  w.Header().Set(“Content-Encoding”, “gzip”)

  gz := gzip.NewWriter(w)
  err := json.NewEncoder(gz).Encode(res)
  “`

• 資深大佬 : solos

  @nanmu42 那我得换一下 哈哈

• 資深大佬 : heiheidewo

  @nanmu42 我几年前就用了这个 gin-contrib/gzip，一直很稳定，这个有啥问题么

• 資深大佬 : solos

  @nanmu42 我试了下 html 没有压缩 只有 json 压缩了

• 主 資深大佬 : nanmu42

  @heiheidewo @Allianzcortex
  gzip 压缩本身只是调用官方库，不难。要考虑的主演是另外的问题：
  客户端支持解压缩吗？（不支持就不能压缩）
  哪些内容类型需要压缩？判断基于 MIME 还是扩展名？（都要判断）
  数据流是不是已经压缩过？（看 header ）
  返回最少要多大才值得压缩？（返回太小，压缩后更大，得不偿失）
  使用哪一个 gzip 级别？（ cloudflare 做了一堆实验，nginx 直接取 1，这个问题是玄学）
  流式传输的返回该如何判断返回大小？（ buffer，没别的办法，content-length 这时不存在）

  主要是脏活累活，细节问题，性能问题（ GC 要友好）。

  gin-contrib 只是看上去好，它 issue 里的问题其实就是上面这些点的体现，关键是官方并不怎么上心…… （他 issue 的链接请看上，v2 系统不让我再发一遍了）

• 主 資深大佬 : nanmu42

  @solos 中间件默认的配置不会盲目压缩，比如返回太小不压缩（得不偿失），客户端不支持不压缩等等。详情可以看下 README 里的默认配置。