h5之缓存探索

对于web页面的缓存苦恼可归为两类(尤其微信内)：1.js，css等资源缓存，2.入口文件html缓存

对于问题1是比较好解决的，用加query版本号（index.js?v=2019314）或打包md5文件名都可解决（ index.a769sh7f9d.js）,打包md5文件名的做法对现代前端项目是最常用的，但也带来一个问题，一旦发生问题2即入口文件html被缓存就会发生资源404的情况，具体原因就不详述了，重点是问题2

进入正题，要解决入口文件html缓存问题有两个方向（有很多乱七八糟的方法，并不能通过理论推演，实际也并无效果，暂不讨论）：
1>nginx(或其他web容器服务端)做302，其原理是用户每次点击的链接都不会直接指向一个实际的html文件，302后才“抵达目的地”，这么做可以保证每次点击都是形成这样的链路，nginx302拿到的html一定是最新的
2>想办法让浏览器客户端不去缓存html文件，但怎么让它不缓存呢？能想到有两种手段，一个是加html加meta标签告诉浏览器不能缓存“我”，一个是服务端设置响应头加上no-cache

标签方法：

1.加meta标签

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />

2.在html标签中增加不存在的manifest文件链接,与加meta标签形式如出一辙，可归为一类

<html manifest="IGNORE.manifest">

服务端设置header：

#### kill cache
        add_header Last-Modified $date_gmt;
        add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
        if_modified_since off;
        expires off;
        etag off;

从上面可以看出，两种方案都涉及到了http协议，所以很有必要对http进行探索

一个很有意思的现象：一个项目中request header中带有cache-control: no-cache，而response里并没有带

image.png

来看一下MDN解释：

image.png

关于If-Modified-Since：

image.png

还有关于Expires头：

image.png

关于ETag：

image.png

这些基本上解释了上面ngnix add_header的一系列内容的具体意义

再偷一张完整的流程图：

image.png

为什么不选择meta标签？一方面meta标签只被部分浏览器支持，还有就是代理不解析HTML内容本身

所以综上所述，自古华山一条路，有效避免入口文件缓存的方法只有302和服务响应头

设置cache-control响应头后，客户端Response Headers

同时把etag，if_modified_since，expires 关掉，即响应头中不再有这些键值，重新进行缓存协商

测试缓存

当服务端及项目文件什么都不做时，第一次进入200，刷新后变成304，会被磁盘缓存，且在失效前每次都会被读
做了302后每次进入都会先有个302，再会有200，不会读取磁盘缓存
设置服务响应头后，每次请求都200，不会读取磁盘缓存

补充

加时间戳是否有效？时间戳并不会起到效果，这句话的意思是在于特殊应用场景，如果页面内跳转的话，时间戳是可以起到效果的，但是如果像微信分享链接出去，一个用户点击后把带时间戳的入口文件缓存到本地后，以后点击该链接时间戳也不会被刷新，这样是没有效果的，所以真正起到效果的是时间戳过期后的302，如果没有302，依然会从缓存中获取

附：1.https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control
2.http://coolnuanfeng.github.io/webCache

h5之缓存探索