1. 浏览器缓存机制存在的问题点
浏览器的缓存机制，主要分为强缓存和协商缓存，两者的主要区别在于是否需要向服务器发送请求验证资源是否有效。
为什么要使用缓存
第一次打开该网站后，如果再次刷新页面。会发现浏览器加载的众多资源中，有一部分size有具体数值，然而还有一部分请求，比如图片、css和js等文件并没有显示文件大小，而是显示了 from dis cache 或者 from memory cache 字样。这就说明了，该资源直接从本地硬盘或者浏览器内存读取，而并没有请求服务器。
浏览器启用缓存至少有两点显而易见的好处： （1）减少页面加载时间；（2）减少服务器负载；
浏览器是否使用缓存、缓存多久，是由服务器控制的。准确来说，当浏览器请求一个网页（或者其他资源）时，服务器发回的响应的「响应头」部分的某些字段指明了有关缓存的关键信息。
强缓存
强缓存主要是通过http请求头中的cache-control和expire两个字段控制
一般设置cache-control的字段值：“public, max-age=xxx”表示在xxx秒内再次访问该资源都可以读取本地缓存，不再向服务器发起请求。
如果xxx秒内，服务器的内容更新了，那么客户端在没有强制刷新的情况下，访问的还是旧的资源。
协商缓存
协商缓存的主要问题是每次都要向服务器验证缓存的有效性，其实消耗也很大。
Expires>Cache-Control>## Last-Modified&Etag
如果资源已经被浏览器缓存下来，在缓存失效之前，再次请求时，默认会先检查是否命中强缓存，如果强缓存命中则直接读取缓存，如果强缓存没有命中则发请求到服务器检查是否命中协商缓存，如果协商缓存命中，则告诉浏览器还是可以从缓存读取，否则才从服务器返回最新的资源
2.最佳实践
缓存的意义在于减少http请求，更多地使用本地的资源，给用户更好的体验的同时，也减轻服务器压力，所以最佳实践，就是尽可能命中强缓存，同时，在更新版本的时候让客户端的缓存失效。
在更新版本之后，如何让用户第一时间使用最新的资源呢？最简单的方法就是修改路径，每次发布都加上一个版本号，这样每次发布之后的第一次访问，都相当于第一次访问这些资源，就不会存在缓存的问题了。
webpack让我们在打包的时候，可以在文件名的末尾加上hash值
**
entry: {
main: path.join(__dirname, './main.js'),
vendor: ['react', 'antd']
},
output: {
path: path.join(__dirname, './dist),
publicPath: '/dist/',
filename: 'bundle.[chunckhash].js'
}
所以综上所述，可以考虑一个方案
HTML：使用协商缓存
css、js、图片等资源：使用强缓存，文件名带上hash值
hash也有讲究
webpack提供了三种hash计算方式，分别是hash、chunkhash和contenthash。
hash：跟整个项目的构建相关，构建生成的文件hash都是一样的，只要项目里有文件更改，更个项目构建的hash都会改变。
缺点：hash是工程级别的，每次修改文件，所有的文件名都将改变。所以一旦修改了一个文件，整个项目的文件都将失效。对于没有改变的模块而言，这样做显然是不恰当的。
chunkhash：根据不同的入口文件（entry）来进行文件解析、构建对应的chunk，生成对应的hash值。
优点：在生产环境中将公共库和程序入口文件区分开，单独打包构建。只要不动到公共库的代码，就能保证其哈希值不会变化。
缺点：由于css文件是作为模块import到js文件的，所以他们的chuckhash是一致的。当css发生改变的时候，其管关联文件的hash值也会改变，但内容其实并没有改变，所以没有达到缓存的意义。
contenthash：由文件内容产生的hash值，内容不同产生的contenthash值也不一样
contenthash是针对文件内容级别的，只有你自己的模块的内容变化了，那么hash才会改变。所以contenthash可以解决上述的问题。
。
