关于html缓存设置

通过HTTP的META设置expires和cache-control

指令不区分大小写，并且具有可选参数，可以用令牌或者带引号的字符串语法。多个指令以逗号分隔。

客户端可以在HTTP请求中使用的标准 Cache-Control 指令。

Cache-Control: max-stale[=<seconds>]

Cache-Control: min-fresh=<seconds>

Cache-control: no-cache

Cache-control: no-store

Cache-control: no-transform

Cache-control: only-if-cached

服务器可以在响应中使用的标准 Cache-Control 指令。

Cache-control: no-cache

Cache-control: no-store

Cache-control: no-transform

Cache-control: public

Cache-control: private

Cache-control: proxy-revalidate

Cache-Control: max-age=<seconds>

Cache-control: s-maxage=<seconds>

拓展缓存指令不是HTTP缓存标准的一部分，使用前请注意检查 兼容性 ！

Cache-control: immutable

Cache-control: stale-while-revalidate=<seconds>

Cache-control: stale-if-error=<seconds>

public

表明响应可以被任何对象（包括：发送请求的客户端，代理服务器，等等）缓存。

private

表明响应只能被单个用户缓存，不能作为共享缓存（即代理服务器不能缓存它）。

no-cache

强制所有缓存了该响应的缓存用户，在使用已存储的缓存数据前，发送带验证器的请求到原始服务器

only-if-cached

表明如果缓存存在，只使用缓存，无论原始服务器数据是否有更新

max-age=<seconds>

设置缓存存储的最大周期，超过这个时间缓存被认为过期(单位秒)。与Expires相反，时间是相对于请求的时间。

s-maxage=<seconds>

覆盖max-age 或者 Expires 头，但是仅适用于共享缓存(比如各个代理)，并且私有缓存中它被忽略。

max-stale[=<seconds>]

表明客户端愿意接收一个已经过期的资源。 可选的设置一个时间(单位秒)，表示响 应不能超过的过时时间。

min-fresh=<seconds>

表示客户端希望在指定的时间内获取最新的响应。

must-revalidate

缓存必须在使用之前验证旧资源的状态，并且不可使用过期资源。

proxy-revalidate

与must-revalidate作用相同，但它仅适用于共享缓存（例如代理），并被私有缓存忽略。

immutable

表示响应正文不会随时间而改变。资源（如果未过期）在服务器上不发生改变，因此客户端不应发送重新验证请求头（例如If-None-Match或If-Modified-Since）来检查更新，即使用户显式地刷新页面。在Firefox中，immutable只能被用在 https:// transactions.

发送如下指令可以关闭缓存。此外，可以参考Expires 和 Pragma 标题。

对于应用程序中不会改变的文件，你通常可以在发送响应头前添加积极缓存。这包括例如由应用程序提供的静态文件，例如图像，CSS文件和JavaScript文件。另请参阅Expires标题。

缓存主要两个策略 强制缓存 ，协商缓存

强制缓存就是设置本地资源html img js等等缓存多长时间 超过时间就去服务器端取。

协商缓存就是每次都询问服务器资源是否已经过期 没有过期就使用缓存 已经过期就从服务器上重新取。

缓存流程可以分三个阶段 本地缓存，协商缓存 ，缓存失败

现在的vue项目里都不是这样缓存的 我个人感觉这是在静态页面时的缓存办法

现在都是webpack打包时通过 hash chunkhash contenthash来决定缓存方式 主要就是在请求的文件名称后面加一个id 来判断文件是否已经更新。

解决index.html缓存问题

一般项目发版后前端静态文件会有缓存问题，

不强制刷新很难解决，

但是用户不会去强制刷新，

这就需要我们开发人员在配置方面解决浏览器缓存静态文件问题。

一般浏览器缓存的文件有html、css、js等。

css、js文件被缓存的解决方案

一般html中引入的css和js的名字都加了哈希值，所以新版本css、js和就旧版本的名字是不同的，不会有缓存问题。

如果index.html文件被缓存就稍微麻烦些

首先可以在index.html文件头部添加mate标签禁止缓存

<meta http-equiv="Expires" content="0">

<meta http-equiv="Pragma" content="no-cache">

<meta http-equiv="Cache-control" content="no-cache">

<meta http-equiv="Cache" content="no-cache">

浏览器的缓存解决，

但是一般在服务器端还是会有缓存，

当浏览器访问index.html时拿到的就是服务器缓存的文件，所有我们还需要解决服务器的缓存

这需要在服务器配置不让缓存index.html

nginx 配置如下：

location = /index.html {

add_header Cache-Control "no-cache, no-store"

}

近期在发版验证时遇到一个问题，微信公众号登入后页面显示的是老的，强制刷新后，再退出重新登入，仍然显示的是老的页面；

经过一番查找得到了解决方案：

（1）公众号放的菜单地址后加 ?version=1.0.0 每次更新页面则更新菜单；

但是这样每次发版还得修改公众号的菜单，多一步很不方便；

于是和前端一块尝试寻找到另一中解决方案：

（2）前端在html的header中加入缓存策略

<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" />

<meta http-equiv="Cache" content="no-cache" />

这样就彻底解决了缓存问题；

但是注意，往往遇到此问题时，已经缓存了没有加缓存策略的html文件，需要清除掉缓存，加载新的带缓存策略的html文件，将来才会实时更新；但是也不能让用户每个都清理缓存啊；

于是就要配合第一种解决方法，在菜单链接后面加参数，这样用户侧会重新load新版本的html（微信菜单设置发布后，有将近10分钟的延时），这样配合使用就完美解决了我们的问题；

期间多次尝试发现，微信的缓存策略和页面地址的后缀参数相关，使用相同的后缀，在不设置缓存策略下，就能回到对应的版本，很强大，也很鸡肋

---