@titivillage 这里是 BH8VYW，73 。:)

@a719114136 体会精神。

@zgray2580 你好，云南昆明，昆钢大厦。

@evil0harry 收到。

@evil0harry 欢迎投递简历，现在挺缺人的。

@ynyounuo S1 单人的可玩性太低了，可以看看所在城市有没有 DJI 的体验店，扎堆会好玩一点。

@ynyounuo 据我所知没有，倒是有开发者比赛，报名入围免费升，不含机械臂。

@ynyounuo 目前大疆的态度比较暧昧，可能内部对产品的定位还有争议，这个价钱确实贵了。

@ynyounuo 主控升级了，多了些配件，比如机械臂。
https://www.dji.com/cn/mobile/robomaster-ep

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

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

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

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

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

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

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

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

@ccpp132 AC 自动机确实快得飞起，也用不着自己去切，方便。

@diveIntoWork 对前端透明，浏览器解决了，不用关注的。

@xiangyuecn 有 2K 的 buffer，私有不可调。
我觉得压缩这事在 net/http 里解决了的话真的挺好的，当然用中间件也不是不行。

@ihciah 是的，完全匹配 map 是个好办法。
MIME 不是完全匹配（可能会在末尾多一个; charset: utf8 ），所以没用上。
benchmark 下来，这个用例下 AC 自动机比 String.Contains 还要快。