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

[nanmu42]

一个适用于Gin和net/http的 gzip 中间件，可直接用也可定制参数和过滤器，gzip 压缩你的返回。

项目地址： https://github.com/nanmu42/gzip

p.s.

gzip 一般可以将文本返回（例如 JSON ）压缩到 30%~70%.

有的人喜欢在反向代理上做压缩，有的人喜欢在程序里就压缩，萝卜青菜各有所爱。:)

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

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

gin-contrib 只是看上去好，它 issue 里的问题其实就是上面这些点的体现，关键是官方并不怎么上心……

[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 里的默认配置。

[xcstream]

有的人喜欢在数据库里做计算，有人的人喜欢在程序里做计算。（滑稽）