前言
最近遇到了一个HTTP请求返回一个gz压缩包的问题，前前后后搞了3天，总算是把整个流程以及处理的细节搞明白了，总结一篇博客记录分享一下。
问题描述几解决方案
流量方的优化
获取某推广告成效数据的时候由于数据量很多，可能会导致Response数据量过大从而造成请求失败的问题。
某推服务方设计了这样一种方式：先将请求的到的数据写入到一个json文件中，然后将这个json文件使用gzip压缩（经过实际测试，一个100多k大小的json文件使用gzip压缩后只有十几k的大小，并且gzip压缩后是不保留原文件的）。
最终服务端存的是一个压缩后的gz文件，然后返回给用户端一个链接，用户根据这个链接去“下载”压缩后的数据文件，大大减少了网络带宽的占用！
比如我们可以通过下面这个链接下载成效数据：成效数据链接
也就是说，与我们平时处理的请求不同的是，现在这种情况下发送GET请求得到的是一个gz文件的数据流。
解决思路
其实解决问题的思路有2个：一个是根据gz数据流将gz文件写入到本地，然后在本地解压这个文件，读取解压后的文件；另外一种思路是直接根据gz数据流将json文件解压到本地，省去了中间在本地生成gz压缩文件的过程！
一目了然：在上面描述的业务场景中，肯定是第二种解决方案最优！
优化的三方包
从网上找了一个包去处理文件解压缩的问题，但是其源码本身有一些问题，略微修改了一下其源码后便可使用了。
最终修改后的项目地址请访问：Unpackit
原文件存在的问题可以看README的描述。
解决问题的demo
自己写了一个demo专门用来展示两种解决方案的实现过程。
麻雀虽小，五脏俱全，这个demo用到了自定制错误、http的连接池，以及go中常用的错误返回机制。
项目地址如下，欢迎star：https://gitee.com/huoyingwhw/unpackit-demo
细节记录
关于一些解决问题中间的细节请查看笔者另外2篇博客：