前端详解前端缓存，解决前端换包之后环境中仍会出现旧版效果

　　前端项目修改了很多东西：比如bug啊，样式啊。当你把前端项目打包之后满心欢喜的在Nginx（测试环境）换上它，然后在Jira上修改bug状态测试人员复测。然后测试人员开始找你battle了，你的bug怎么还是没修改啊，但是你明明换上了最新的版本，中间到底出现了什么问题。打开控制台的network，显示如图所示。
　　问题就出在fromdiskcache这玩意上，也就是浏览器缓存，浏览器读取的还是缓存中旧版的资源，渲染出来的还是旧版的效果。除了diskcache外，还有其他几类浏览器缓存，总的来说，浏览器缓存大致分为4种，而这4种方式是有优先级顺序的，只有依次查找缓存且都没有命中的时候，才会去请求网络：ServiceWorker：是一种独立于主线程之外的Javascript线程。它脱离于浏览器窗体，可以帮我们实现离线缓存、消息推送和网络代理等功能。MemoryCache：存在内存中的缓存。包括当前中页面中已经抓取到的资源，例如页面上已经下载的样式、脚本、图片等。因为存储在内存中，MemoryCache是响应速度最快的一种缓存，但由于同样的原因，缓存持续性很短，会随着进程的释放而释放，一旦我们关闭Tab页面，内存中的缓存也就被释放了。DiskCache：DiskCache也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之MemoryCache胜在容量和存储时效性上。会根据HTTPHerder中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。PushCache：PushCache是HTTP2在serverpush阶段存在的缓存，当以上三种缓存都没有命中时，它才会被使用，PushCache是一种存在于会话阶段的缓存，当session终止时，缓存也随之释放。不同的页面只要共享了同一个HTTP2连接，那么它们就可以共享同一个PushCache。
　　其实常见的情况下只有diskcache和memorycache，如下图博客园首页请求所示：
　　至于什么情况下是存在内存，还是存在硬盘。由于计算机内存有限，而且比硬盘容量小很多，浏览器会根据计算机具体情况来决定缓存放在内存中还是硬盘中。一般情况下，较大的css文件、js文件和jpg图片这类大文件会被存入硬盘；当前系统内存使用率高的话，文件也会被优先存储进硬盘；而Base64格式的图片，几乎永远可以被塞进内存。
　　那为什么需要缓存呢，对前端来说，因为读缓存不需要发起请求，也就不需要考虑请求环境和速度，提高访问速度，用户体验大大提升；对于后端而言，也缓解了服务器的压力，减少网络IO消耗，减少带宽消耗。
　　但是什么时候需要缓存，什么时候不需要缓存。很明显，我这种换版操作肯定是需要重新获取新的资源的。最简单的解决办法就是CtrlF5强制刷新，强制告诉浏览器不获取缓存，必须重新去获取新的资源，但是强制刷新这种手动触发还是对用户体验不太友好。特别是我们做的后台管理系统，在图片很少的情况下，有没有办法每次换版之后都获取最新的资源。这个时候就要涉及浏览器的缓存策略了，常见的缓存策略有强缓存和协商缓存。其实浏览器的缓存策略都是通过设置HTTPHeader来实现的。
　　强缓存
　　不会向服务器发送请求，直接从缓存中读取资源。状态码：200，显示fromdiskcache或frommemorycache。通过设置两种HTTPHeader实现：Expires和CacheControl。
　　1。Expires：值是一个时间戳，表示本地时间到这个设置的时间缓存就失效。这样一来Expires就是有问题的，受限于本地时间，我直接手动去把电脑端的时间改掉，都能导致缓存失效，所以更推荐使用CacheControl，或者二者搭配使用。
　　在Nginx中配置写法如下：gif、jpg、jpeg、png、bmp、ico这类的资源会在30天后失效location。（gifjpgjpegpngbmpico）｛rootXXXXxxxx；expires30d；｝
　　2。CacheControl：优先级比Expires高，同时设置Expires和CacheControl则后者生效。可以在请求头或者响应头中设置，并且可以组合使用多种指令：private（默认）：只能在浏览器中缓存，只有在第一次请求的时候才访问服务器，若有maxage，则缓存期间不访问服务器public：可以被任何缓存区缓存，如：浏览器、服务器、代理服务器等nocache：可以缓存，但每次都应该去服务器验证缓存是否可用，进入协商缓存阶段，若有maxage，则缓存期间不访问服务器，nostore：不仅不能缓存，连暂存也不可以（即：临时文件夹中不能暂存该资源）maxage：以秒为单位的缓存时间，maxage60，表示缓存60秒后失效，60秒内再次访问该资源，均使用本地的缓存，不再向服务器发起请求smaxage：同maxage作用一样，只在代理服务器中生效（比如CDN缓存），smaxage优先级高于maxage，只对public缓存有效。设置了smaxage，没设置public，代理服务器也可以缓存这个资源mustrevalidate：可缓存但必须再向源服务器进确认proxyrevalidate：要求中间缓存服务器对缓存的响应有效性再进行确认liol
　　在Nginx中配置写法如下，随便举一个指令：location。。（cssjsswfphphtmhtml）｛addheaderCacheControlnostore；｝
　　协商缓存
　　当CacheControl和Expires过期或者它的属性设置为nocache时（即不走强缓存），那么浏览器第二次请求时就会与服务器进行协商，服务器端会对比判断资源是否进行了修改更新，对比结果无非是以下两种：如果服务器端的资源没有修改（NotModified），那么就会返回304状态码，告诉浏览器可以使用缓存中的数据。如果数据有更新就会返回200状态码，服务器就会返回更新后的资源并且将缓存信息一起返回。
　　至于浏览器是怎么和服务器交互，主要是依靠跟协商缓存相关的header头属性：LastModifiedIfModifiedSince、ETagIfNoneMatch。这些属性在请求头和响应头是成对出现的。
　　1。LastModifiedIfModifiedSince：
　　浏览器在第一次访问资源，或缓存过期后访问，服务器返回资源的同时，在responseheader中添加LastModified的header，值是这个资源在服务器上的最后修改时间，浏览器接收缓存文件和header信息。随后我们每次请求时，浏览器会自动带上一个叫IfModifiedSince的时间戳字段给服务器，它的值正是上一次response返回给它的Lastmodified值，然后服务器会根据IfModifiedSince的值对比资源的最后修改时间判断资源是否进行了修改更新。
　　2。ETagIfNoneMatch：
　　Etag是由服务器为每个资源生成的唯一的标识字符串，这个标识字符串是基于文件内容编码的，只要文件内容不同，它们对应的Etag就是不同的，因此Etag能够精准地感知文件的变化。Etag和LastModified类似，当首次请求时，我们会在响应头里获取到一个最初的标识符字符串。那么下一次请求时，浏览器就会在请求头里就会带上一个值相同的、名为ifNoneMatch的字符串供服务器比对。Etag的优先级会比LastModified高，但是Etag因为要生成，也会更消耗服务器性能。
　　查看Nginx更新日志可知，在2014年6月26日就默认开启Etag，对应的版本为1。7。3，也就是说1。7。3及以上的版本的Nginx默认开启Etag。不过需要注意的是，如果Nginx有开启Gzip，可能会与Etag有冲突。
　　然后就是各家的Etag生成情况都不太一样，取决于服务器的类型或配置的算法。以下是简书首页随便的一个请求，这个不是什么大问题，顺便提一嘴。
　　说了这么多，前端缓存最理想的效果就是希望能尽可能多的命中强缓存，对于频繁变动的资源，多使用协商缓存，同时，能在更新版本的时候让浏览器的缓存失效。这就要求了我们对资源进行Nginx配置的时候，对资源失效时间有个自己的衡量和把握。
　　最后，还有一种情况是浏览器在几次刷新过程中会出现新版效果，也会出现旧版效果，新旧交替。那就得考虑前端项目是否布置了多节点，并使用Nginx配置负载均衡了，如果是这个问题的话，只要全部Nginx节点环境都换上新打的前端包问题就迎刃而解了。
　　文章来源：https：www。cnblogs。comjdWudp12918311。html