强缓存和协商缓存
在介绍缓存的时候，我们习惯将缓存分为强缓存和协商缓存两种。两者的主要区别是使用本地缓存的时候，是否需要向服务器验证本地缓存是否依旧有效。
顾名思义，协商缓存，就是需要和服务器进行协商，最终确定是否使用本地缓存。
两种缓存方案的问题点
强缓存
我们知道，强缓存主要是通过http请求头中的Cache-Control和Expire两个字段控制。Expire是HTTP1.0标准下的字段，在这里我们可以忽略。我们重点来讨论的Cache-Control这个字段。
一般，我们会设置Cache-Control的值为“public, max-age=xxx”，表示在xxx秒内再次访问该资源，均使用本地的缓存，不再向服务器发起请求。
显而易见，如果在xxx秒内，服务器上面的资源更新了，客户端在没有强制刷新的情况下，看到的内容还是旧的。
如果发布新版本的时候，后台接口也同步更新了，那就gg了。有缓存的用户还在使用旧接口，而那个接口已经被后台干掉了。那怎么办呢？
协商缓存
协商缓存最大的问题就是每次都要向服务器验证一下缓存的有效性，似乎看起来很省事，不管那么多，你都要问一下我是否有效。但是，每次都去请求服务器，那要缓存还有什么意义。
最佳实践
缓存的意义就在于减少请求，更多地使用本地的资源，给用户更好的体验的同时，也减轻服务器压力。
所以，最佳实践，就应该是尽可能命中强缓存，同时，能在更新版本的时候让客户端的缓存失效。
在更新版本之后，如何让用户第一时间使用最新的资源文件呢？
机智的前端们想出了一个方法，在更新版本的时候，顺便把静态资源的路径改了，这样，就相当于第一次访问这些资源，就不会存在缓存的问题了。
webpack可以让我们在打包的时候，在文件的命名上带上hash值。
entry:{ main: path.join(__dirname,'./main.js'), vendor: ['react', 'antd'] }, output:{ path:path.join(__dirname,'./dist'), publicPath: '/dist/', filname: 'bundle.[chunkhash].js' }
综上所述，我们可以得出一个较为合理的缓存方案：
- HTML：使用协商缓存。
- CSS&JS&图片：使用强缓存，文件命名带上hash值。
CDN缓存
CDN的全称是Content Delivery Network，即内容分发网络。是架设在客户端和服务器之间的Cache层。
大致来讲，客户端请求资源时，CDN对域名解析进行了调整，然后返回一个CNAME，浏览器对CNAME进行解析后得到了CDN服务器的ip，CDN服务器上存在请求的资源就返回本地缓存，不存在则CDN服务器向真正的服务器发出请求，获得资源后缓存在本地，并返回给客户端，实现整个流程。
优点：CDN缓存主要起到客户端跟服务器之前地域的问题，减少延时，分流作用，降低服务器的流量，减轻服务器压力