今天在github上下载了一个开源项目，然后AndroidStudio打开，报了以下错误：

Failed to open zip file. Gradle's dependency cache may be corrupt (this sometimes occurs after a network connection timeout.) 

Re-download dependencies and sync project (requires network)

Re-download dependencies and sync project (requires network)

虽然系统给出了解决方案，但是点击它重新下载依然没有什么用处，百度搜了搜，发现几篇博客千篇一律给出的都不是本质上的解决方案。所以就有了这篇东西。
我知道有些人只想解决问题而不想管原因，所以先上解决方案：

解决方案

首先看一下你报错工程的gradlewrapper设置：

gradlewrapper设置
然后windows资源管理器打开C:\Users\Administrator\.gradle\wrapper\dists这个目录，直接删掉跟上面版本一致的文件夹，然后再次build工程，它会重新下载gradle，这个可能会耗时比较长，下载完毕后，问题就解决了。

为什么？

这里要扯到一个概念：gradlewrapper。
gradle作为一个构建工具，它本身的版本也是在不断迭代更新的，这就可能出现一种情况：一个团队合作的项目，每个人的电脑上gradle版本不一定相同，如果这样，由于升级带来的接口或实现不一致问题就会很严重（接口的破坏性升级会导致无法编译，实现不同则有可能带来隐患）。
为了避免出现这种情况，gradle采用了一种策略，就是gradlewrapper。每个工程下都有gradlewrapper配置文件，上面记录了这个工程使用的gradle版本，当有新成员下载了这个工程时，并不需要在电脑上手动安装gradle，而是在编译时由gradle-wrapper.jar根据gradle-wrapper.properties中的配置到gradle本地仓库去检索对应版本的gradle作为本工程的构建工具，如果本地仓库没有对应版本的gradle，则通过网络到远程仓库（gradle官方）去下载。
说到这里，大家肯定都明白了，上面提到的C:\Users\Administrator\.gradle\wrapper\dists这个就是gradle本地仓库。而为什么会出现本文提到的错误？那是因为，本地仓库中对应版本的gradle文件压缩包出现了问题，可能是这个压缩包本身损坏了，也可能是这个压缩包是很早期的版本，过后被替换过，但又没换名字（后面这种是我自己猜测的，官方应该不至于干这种不专业的事吧。。。）。
为了验证我的猜测，我首先到本地仓库中找到对应版本的文件夹（本工程是4.6版本gradle），文件夹里面只有一个乱七八糟字符的文件夹（应该是某种规则的唯一编码），点进去，发现了以下两个文件：

gradle4.6版本目录
然后我再回到本地仓库，对比一下完全没问题的4.4版本，发现内容是这样：
gradle4.4版本目录
观察一下就能发现，4.4目录里那个文件夹就是把压缩包给解压了，那为什么4.6没有解压？我回到4.6的文件夹里用压缩工具手动解压那个安装包，在解压的最后，解压工具报了几个错误，不过还是解压出了一些文件。我们知道，gradle是用groovy来解压zip文件，如果这个过程中报错了，它会遵守事务，把残缺的解压结果删掉，所以就有了本文描述的错误。
ok。我把有问题的4.6改个名字，重新编译，这样跟删除是一个效果，目的是看看新下载的文件跟老的有什么区别。
有问题的老压缩包 新下载的压缩包

看到区别了么？新的比老的大一些，至于是不是老的在传输过程中受损那就不得而知了。
最后，我用解压工具解压这个新压缩包，也并不会报任何错误。
这才是真正解决了问题。