前端缓存最佳实践

前言

缓存，这是一个老生常谈的话题，也常被作为前端面试的一个知识点。

本文，重点在与探讨在实际项目中，如何进行缓存的设置，并给出一个较为合理的方案。

强缓存和协商缓存

在介绍缓存的时候，我们习惯将缓存分为强缓存和协商缓存两种。两者的主要区别是使用本地缓存的时候，是否需要向服务器验证本地缓存是否依旧有效。顾名思义，协商缓存，就是需要和服务器进行协商，最终确定是否使用本地缓存。

两种缓存方案的问题点

强缓存

我们知道，强缓存主要是通过http请求头中的Cache-Control和Expire两个字段控制。Expire是HTTP1.0标准下的字段，在这里我们可以忽略。我们重点来讨论的Cache-Control这个字段。

一般，我们会设置Cache-Control的值为“public, max-age=xxx”，表示在xxx秒内再次访问该资源，均使用本地的缓存，不再向服务器发起请求。

显而易见，如果在xxx秒内，服务器上面的资源更新了，客户端在没有强制刷新的情况下，看到的内容还是旧的。如果说你不着急，可以接受这样的，那是不是完美？然而，很多时候不是你想的那么简单的，如果发布新版本的时候，后台接口也同步更新了，那就gg了。有缓存的用户还在使用旧接口，而那个接口已经被后台干掉了。怎么办？

协商缓存

协商缓存最大的问题就是每次都要向服务器验证一下缓存的有效性，似乎看起来很省事，不管那么多，你都要问一下我是否有效。但是，对于一个有追求的码农，这是不能接受的。每次都去请求服务器，那要缓存还有什么意义。

最佳实践

缓存的意义就在于减少请求，更多地使用本地的资源，给用户更好的体验的同时，也减轻服务器压力。所以，最佳实践，就应该是尽可能命中强缓存，同时，能在更新版本的时候让客户端的缓存失效。

在更新版本之后，如何让用户第一时间使用最新的资源文件呢？机智的前端们想出了一个方法，在更新版本的时