整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker的话，传输协议必为HTTPS
内存中的缓存，读取高效，缓存的持续性段，会随着进程的结束而释放，例如关闭页面，内存中的缓存就被释放了内存缓存中有一块重要的缓存资源是preloader相关指令（例如<link rel="prefetch">）下载的资源。它可以一边解析js/css文件，一边网络请求下一个资源。
存储在硬盘中的缓存，读取速度慢点，绝大部分的缓存都来自Disk Cache，在HTTP 的协议头中设置（？）。
是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被使用。它只在会话（Session）中存在，一旦会话结束就被释放，并且缓存时间也很短暂，在Chrome浏览器中只有5分钟左右，同时它也并非严格执行HTTP头中的缓存指令。
根据是否需要向服务器重新发起 http 请求分为强缓存和协商缓存两种类型。强缓存的优先级要高于协商缓存。
强缓存机制下浏览器首先查找本地缓存，如果命中则不会向服务器发起请求。此时返回 200 状态码，并带有 from disk cache 或 from memory cache 字样。强缓存可以通过设置两种 HTTP Header 实现：Expires 和 Cache-Control。
Expires
是 HTTP/1.0 的产物，受限于本地时间
Cache-Control
Cache-Control在 HTTP/1.1中，Cache-Control 是最重要的规则，主要用于控制网页缓存。
1. public
响应可被任何中间节点缓存，如 Browser <-- proxy <-- Server，中间的 proxy 可以缓存资源，比如下次再请求同一资源时 proxy 直接把自己缓存的内容给 Browser 而不再向 Server 要。
2. private
所有内容只有客户端可以缓存，Cache-Control 的默认取值。中间节点不允许缓存,当下次 Browser 再次请求时 proxy 会做好请求转发而不是自作主张给自己缓存的数据。
协商缓存可以通过设置两种 HTTP Header 实现：Last-Modified 和 ETag。
3.no-cache
客户端缓存内容，是否使用缓存则需要经过协商缓存来验证决定。表示不使用 Cache-Control 的缓存控制方式做前置验证，而是使用 Etag 或者 Last-Modified 字段来控制缓存。
4. no-store
所有内容都不会被缓存，既不使用强缓存，也不使用协商缓存
5. max-age
max-age=xxx(xxx is numeric) 表示缓存内容将在 xxx 秒后失效must-revalidate如果超过了 max-age 的时间，浏览器必须向服务器发送请求，验证资源是否还有效。
6. s-maxage
设置共享缓存，比如can。会覆盖max-age和expires；只用于共享缓存（如CDN缓存）
7. no-transform
不得对资源进行转换和转变。例如，不得对图像格式进行转换。
Cache-Control 优先级高于 Expires
协商缓存就是强缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，主要有以下两种情况：
> 协商缓存生效，返回 304 和 Not Modified。
> 协商缓存失效，返回 200 和请求结果。
协商缓存可以通过设置两种 HTTP Header 实现：Last-Modified 和 ETag。
浏览器在第一次访问资源时，服务器返回资源的同时，在 response header 中添加 Last-Modified 的 header，值是这个资源在服务器上的最后修改时间，浏览器接收后缓存文件和header。
浏览器下一次请求这个资源，浏览器检测到有 Last-Modified 这个 header，于是添加If-Modified-Since 这个 header，值就是 Last-Modified 中的值。服务器再次收到这个资源请求，会根据 If-Modified-Since 中的值与服务器中这个资源的最后修改时间对比，`如果没有变化，返回 304 和空的响应体，浏览器直接从缓存读取。如果 If-Modified-Since 的时间小于服务器中这个资源的最后修改时间，说明文件有更新，则返回新的资源文件和 200。
是服务器响应请求时返回当前资源文件的一个唯一标识（由服务器生成），只要资源有变化，Etag 就会重新生成。浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的 Etag 值放到 request header 里的 If-None-Match 里，服务器只需要比较客户端传来的 If-None-Match 跟自己服务器上该资源的 ETag 是否一致，就能很好地判断资源相对客户端而言是否被修改过了。如果服务器发现 ETag 匹配不上，那么直接以常规 GET 200 回包形式将新的资源（当然也包括了新的 ETag）发给客户端。如果 ETag 是一致的，则返回 304 指示客户端直接使用本地缓存即可。
1. 在精确度上，Etag 要优于 Last-Modified。Last-Modified 的时间单位是秒，如果某个文件在 1 秒内改变了多次，那么他们的 Last-Modified 其实并没有体现出来修改。但是 Etag 每次都会改变确保了精度。如果是负载均衡的服务器，各个服务器生成的 Last-Modified 也有可能不一致。
2. 在性能上，Etag 要逊于 Last-Modified，毕竟 Last-Modified 只需要记录时间，而 Eta g需要服务器通过算法来计算出一个 hash 值。
3. 在优先级上，服务器校验优先考虑 Etag。
强缓存优先级高于协商缓存，若强缓存（Expires 和 Cache-Control）生效则直接使用缓存，若不生效则进行协商缓存（Last-Modified / If-Modified-Since 和 Etag / If-None-Match）。协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，返回 200，重新返回资源和缓存标识，再存入浏览器缓存中；生效则返回 304，继续使用缓存。
那如果什么缓存策略都没设置，浏览器会怎么处理呢？对于这种情况，浏览器会采用一个启发式的算法，通常会取响应头中的 Date 减去 Last-Modified 值的 10% 作为缓存时间
一、HTTP缓存
http请求做为影响前端性能极为重要的一环，因为请求受网络影响很大，如果网络很慢的情况下,页面很可能会空白很久。对于首次进入网站的用户可能要通过优化接口性能和接口数量来解决。但是，对于重复进入页面的用户，除了浏览器缓存，http缓存可以很大程度对已经加载过的页面进行优化。
1.缓存位置
从缓存位置上来看，分为4种，从上往下依次检查是否命中，如果但都没有命中则重新发起请求。
Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker的话，传输协议必须为 HTTPS。
Memory Cache 也就是内存中的缓存，主要包含的是当前中页面中已经抓取到的资源,例如页面上已经下载的样式、脚本、图片等。读取内存中的数据肯定比磁盘快,内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。 一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。
内存缓存中有一块重要的缓存资源是preloader相关指令(例如)下载的资源。它可以一边解析js/css文件，一边网络请求下一个资源。
Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。
绝大部分的缓存都来自Disk Cache，在HTTP 的协议头中设置。
Push Cache(推送缓存)是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被使用。它只在会话(Session)中存在，一旦会话结束就被释放，并且缓存时间也很短暂，在Chrome浏览器中只有5分钟左右，同时它也并非严格执行HTTP头中的缓存指令。
2.用户操作对缓存的影响
下面主要说一下前端优化能入手的地方，也就是强缓存和协商缓存，并且缓存策略都是通过设置 HTTP Header 来实现的。
3.强缓存
浏览器在第一次访问接口后的response headers里会携带一些字段，这些字段决定关于这个请求的缓存情况，
与强缓存相关的header字段有两个：
1、expires：过气网红，这是http1.0时的规范;它的值为一个绝对时间的GMT格式的时间字符串，如Mon, 10 Jun 2015 21:31:12 GMT，如果发送请求的时间在expires之前，那么本地缓存始终有效，否则就会发送请求到服务器来获取资源
2、cache-control：新星：max-age=number，这是http1.1时出现的header信息，主要是利用该字段的max-age值来进行判断，它是一个相对值;资源第一次的请求时间和Cache-Control设定的有效期，计算出一个资源过期时间，再拿这个过期时间跟当前的请求时间比较，如果请求时间在过期时间之前，就能命中缓存，否则就不行;
no-cache：不使用本地缓存。需要使用协商缓存，先与服务器确认返回的响应是否被更改，如果之前的响应中存在ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。
no-store：直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
public：可以被所有的用户缓存，包括终端用户和CDN等中间代理服务器。
private：只能被终端用户的浏览器缓存，不允许CDN等中继缓存服务器对其缓存。
注意：如果cache-control与expires同时存在的话，cache-control的优先级高于expires
强缓存时段命中，会直接从缓存中返回数据，返回值200;这一时间段，不管接口内容有没有变化都不会进行请求更新。
4.协商缓存
当没有强缓存时，会向服务端寻求帮助，也就是问一下服务端有没有更改，向接口判断是否有缓存。如果命中协商缓存则返回304状态码，并且从本地返回缓存内容。如果没有命中，则重新发起请求。
协商缓存需要跟服务端通过特殊标示连接，即第一次请求的响应头带上某个字段(Last-Modified或者Etag)，则后续请求则会带上对应的请求字段(If-Modified-Since或者If-None-Match)，若响应头没有Last-Modified或者Etag字段，则请求头也不会有对应的字段。
具体过程如下：
Last-Modified/If-Modified-Since
1.浏览器第一次跟服务器请求一个资源，respone的header里加上Last-Modified：表示这个资源在服务器上的最后修改时间
2.浏览器再次跟服务器请求这个资源时，在request的header上加上If-Modified-Since的header：上一次请求时返回的Last-Modified的值
3.服务器再次收到资源请求时，会判断最后修改时间是否有变化，如果没有变化则返回304 Not Modified，但是不会返回资源内容;如果有变化，就正常返回资源内容，Last-Modified会被修改为最新的值。如果没有变化，服务器返回304 Not Modified，Last-Modified不会修改，response header中不会再添加Last-Modified的header
4.浏览器收到304的响应后，就会从缓存中加载资源
Etag/If-None-Match
由服务器生成的每个资源的唯一标识字符串，只要资源有变化就这个值就会改变;其判断过程与Last-Modified/If-Modified-Since类似，与Last-Modified不一样的是，当服务器返回304 Not Modified的响应时，由于ETag重新生成过，response header中还会把这个ETag返回，即使这个ETag跟之前的没有变化。
1.一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET;
2.某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒);
3.某些服务器不能精确的得到文件的最后修改时间。
Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。
二、浏览器本地存储
浏览器本地缓存最常用的是cookie、localStroage、sessionStroage、webSql、indexDB。
1.cookie使用
cookie的用法很简单,可以通过服务端设置，js也可以通过documnet.cookie="名称=值;"(不要忘记以;分割)来设置。
cookie的值字符串可以用encodeURIComponent()来保证它不包含任何逗号、分号或空格(cookie值中禁止使用这些值).
cookie一般用做为登陆态保存、密码、个人信息等关键信息保存使用，所以为了安全也是遵守同源策略原则的。
可以通过下面参数具体设置：
;path=path (例如 '/', '/mydir') 如果没有定义，默认为当前文档位置的路径。
;domain=domain (例如 'example.com'， 'subdomain.example.com') 如果没有定义，默认为当前文档位置的路径的域名部分。与早期规范相反的是，在域名前面加 . 符将会被忽视，因为浏览器也许会拒绝设置这样的cookie。如果指定了一个域，那么子域也包含在内。
;max-age=max-age-in-seconds (例如一年为606024*365)
;expires=date-in-GMTString-format 如果没有定义，cookie会在对话结束时过期这个值的格式参见Date.toUTCString()
;secure (cookie只通过https协议传输)
;HttpOnly 限制web页面程序的browser端script程序读取cookie
缺点
容量有限制，不能超过4kb
在请求头上带着数据安全性差
2.localStorage和sessionStorage使用
html5新增本地存储，localStorage生命周期是永久，除非主动清除localStorage信息，否则这些信息将永远存在。存放数据大小为一般为5MB,sessionStorage仅在当前会话下有效，关闭页面或浏览器后被清除。而且它仅在客户端(即浏览器)中保存，不参与和服务器的通信。也是遵守同源策略原则的
// 1、保存数据到本地
// 第一个参数是保存的变量名，第二个是赋给变量的值
localStorage.setItem('key', 'value');
//复杂类型储存需要**利用JSON.stringify**将对象转换成字符串；
//利用**JSON.parse**将字符串转换成对象
// 2、从本地存储获取数据
localStorage.getItem('key');
// 3、从本地存储删除某个已保存的数据
localStorage.removeItem('key');
// 4、清除所有保存的数据
localStorage.clear();
3. Web SQL
WebSQL是前端的一个独立模块，是web存储方式的一种，我们调试的时候会经常看到，只是一般很少使用。并且，当前只有谷歌支持，ie和火狐均不支持。
主要方法：
1.openDatabase：这个方法使用现有的数据库或者新建的数据库创建一个数据库对象。
2.transaction：这个方法让我们能够控制一个事务，以及基于这种情况执行提交或者回滚。
3.executeSql：这个方法用于执行实际的 SQL 查询。
4.indexDB
IndexedDB 就是浏览器提供的本地数据库，它可以被网页脚本创建和操作。IndexedDB 允许储存大量数据，提供查找接口，还能建立索引。这些都是 LocalStorage 所不具备的。就数据库类型而言，IndexedDB 不属于关系型数据库(不支持 SQL 查询语句)，更接近 NoSQL 数据库。
推荐租用天下数据香港服务器；位于天下数据香港自建机房，带宽充足，都采用BGP、CN2线路，不仅解决了南北互通的问题，也极大提升了香港服务器在国内的访问速度，平均Ping值在20ms以内，稳定性好、访问速度快。天下数据香港自建机房速度、所有机器含IPMI自主管理，自动重启，免费重装！详询客服。
看过的大部分讨论缓存的文章会直接从 HTTP 协议头中的缓存字段开始，例如 Cache-Control, ETag, max-age 等。但偶尔也会听到别人讨论 memory cache, disk cache 等。那这两种分类体系究竟有何关联？是否有交叉?
实际上，HTTP 协议头的那些字段，都属于 disk cache 的范畴，是几个缓存位置的其中之一。因此本着从全局到局部的原则，我们应当先从缓存位置开始讨论。等讲到 disk cache 时，才会详细讲述这些协议头的字段及其作用。
我们可以在 Chrome 的开发者工具中，Network -> Size 一列看到一个请求最终的处理方式：如果是大小 (多少 K， 多少 M 等) 就表示是网络请求，否则会列出 from memory cache, from disk cache 和 from ServiceWorker。
它们的优先级是：(由上到下寻找，找到即返回；找不到则继续)
memory cache 是内存中的缓存，(与之相对 disk cache 就是硬盘上的缓存)。按照操作系统的常理：先读内存，再读硬盘。disk cache 将在后面介绍 (因为它的优先级更低一些)，这里先讨论 memory cache。
几乎所有的网络请求资源都会被浏览器自动加入到 memory cache 中。但是也正因为数量很大但是浏览器占用的内存不能无限扩大这样两个因素，memory cache 注定只能是个“短期存储”。常规情况下，浏览器的 TAB 关闭后该次浏览的 memory cache 便告失效 (为了给其他 TAB 腾出位置)。而如果极端情况下 (例如一个页面的缓存就占用了超级多的内存)，那可能在 TAB 没关闭之前，排在前面的缓存就已经失效了。
刚才提过，几乎所有的请求资源 都能进入 memory cache，这里细分一下主要有两块：
memory cache 机制保证了一个页面中如果有两个相同的请求 (例如两个 src 相同的 <img>，两个 href 相同的 <link>) 都实际只会被请求最多一次，避免浪费。
不过在匹配缓存时，除了匹配完全相同的 URL 之外，还会比对他们的类型，CORS 中的域名规则等。因此一个作为脚本 (script) 类型被缓存的资源是不能用在图片 (image) 类型的请求中的，即便他们 src 相等。
在从 memory cache 获取缓存内容时，浏览器会忽视例如 max-age=0, no-cache 等头部配置。例如页面上存在几个相同 src 的图片，即便它们可能被设置为不缓存，但依然会从 memory cache 中读取。这是因为 memory cache 只是短期使用，大部分情况生命周期只有一次浏览而已。而 max-age=0 在语义上普遍被解读为“不要在下次浏览时使用”，所以和 memory cache 并不冲突。
但如果站长是真心不想让一个资源进入缓存，就连短期也不行，那就需要使用 no-store。存在这个头部配置的话，即便是 memory cache 也不会存储，自然也不会从中读取了
disk cache 也叫 HTTP cache，顾名思义是存储在硬盘上的缓存，因此它是持久存储的，是实际存在于文件系统中的。而且它允许相同的资源在跨会话，甚至跨站点的情况下使用，例如两个站点都使用了同一张图片。
disk cache 会严格根据 HTTP 头信息中的各类字段来判定哪些资源可以缓存，哪些资源不可以缓存；哪些资源是仍然可用的，哪些资源是过时需要重新请求的。当命中缓存之后，浏览器会从硬盘中读取资源，虽然比起从内存中读取慢了一些，但比起网络请求还是快了不少的。绝大部分的缓存都来自 disk cache。
关于 HTTP 的协议头中的缓存字段，我们会在稍后进行详细讨论。
凡是持久性存储都会面临容量增长的问题，disk cache 也不例外。在浏览器自动清理时，会有神秘的算法去把“最老的”或者“最可能过时的”资源删除，因此是一个一个删除的。不过每个浏览器识别“最老的”和“最可能过时的”资源的算法不尽相同，可能也是它们差异性的体现。
上述的缓存策略以及缓存/读取/失效的动作都是由浏览器内部判断 & 进行的，我们只能设置响应头的某些字段来告诉浏览器，而不能自己操作。举个生活中去银行存/取钱的例子来说，你只能告诉银行职员，我要存/取多少钱，然后把由他们会经过一系列的记录和手续之后，把钱放到金库中去，或者从金库中取出钱来交给你。
但 Service Worker 的出现，给予了我们另外一种更加灵活，更加直接的操作方式。依然以存/取钱为例，我们现在可以绕开银行职员，自己走到金库前(当然是有别于上述金库的一个单独的小金库)，自己把钱放进去或者取出来。因此我们可以选择放哪些钱(缓存哪些文件)，什么情况把钱取出来(路由匹配规则)，取哪些钱出来(缓存匹配并返回)。
Service Worker 能够操作的缓存是有别于浏览器内部的 memory cache 或者 disk cache 的。我们可以从 Chrome 的 F12 中，Application -> Cache Storage 找到这个单独的“小金库”。除了位置不同之外，这个缓存是永久性的，即关闭 TAB 或者浏览器，下次打开依然还在(而 memory cache 不是)。有两种情况会导致这个缓存中的资源被清除：手动调用 API cache.delete(resource) 或者容量超过限制，被浏览器全部清空。
如果 Service Worker 没能命中缓存，一般情况会使用 fetch() 方法继续获取资源。这时候，浏览器就去 memory cache 或者 disk cache 进行下一次找缓存的工作了。注意：经过 Service Worker 的 fetch() 方法获取的资源，即便它并没有命中 Service Worker 缓存，甚至实际走了网络请求，也会标注为 from ServiceWorker。这个情况在后面的第三个示例中有所体现。
如果一个请求在上述 3 个位置都没有找到缓存，那么浏览器会正式发送网络请求去获取内容。之后容易想到，为了提升之后请求的缓存命中率，自然要把这个资源添加到缓存中去。具体来说：
memory cache 是浏览器为了加快读取缓存速度而进行的自身的优化行为，不受开发者控制，也不受 HTTP 协议头的约束，算是一个黑盒。Service Worker 是由开发者编写的额外的脚本，且缓存位置独立，出现也较晚，使用还不算太广泛。所以我们平时最为熟悉的其实是 disk cache，也叫 HTTP cache (因为不像 memory cache，它遵守 HTTP 协议头中的字段)。平时所说的强制缓存，对比缓存，以及 Cache-Control 等，也都归于此类。
强制缓存的含义是，当客户端请求后，会先访问缓存数据库看缓存是否存在。如果存在则直接返回；不存在则请求真的服务器，响应后再写入缓存数据库。
强制缓存直接减少请求数，是提升最大的缓存策略。 它的优化覆盖了文章开头提到过的请求数据的全部三个步骤。如果考虑使用缓存来优化网页性能的话，强制缓存应该是首先被考虑的。
可以造成强制缓存的字段是 Cache-control 和 Expires。
这是 HTTP 1.0 的字段，表示缓存到期时间，是一个绝对的时间 (当前时间+缓存时间)，如
Expires: Thu, 10 Nov 2017 08:45:11 GMT在响应消息头中，设置这个字段之后，就可以告诉浏览器，在未过期之前不需要再次请求。
但是，这个字段设置时有两个缺点：
已知Expires的缺点之后，在HTTP/1.1中，增加了一个字段Cache-control，该字段表示资源缓存的最大有效时间，在该时间内，客户端不需要向服务器发送请求
这两者的区别就是前者是绝对时间，而后者是相对时间。如下：
Cache-control: max-age=2592000下面列举一些 Cache-control 字段常用的值：(完整的列表可以查看 MDN)
这些值可以混合使用，例如 Cache-control:public, max-age=2592000。
这里有一个疑问：max-age=0 和 no-cache 等价吗？从规范的字面意思来说，max-age 到期是 应该 重新验证，而 no-cache 是 必须 重新验证。但实际情况以浏览器实现为准，大部分情况他们俩的行为还是一致的。
顺带一提，在 HTTP/1.1 之前，如果想使用 no-cache，通常是使用 Pragma 字段，如 Pragma: no-cache(这也是 Pragma 字段唯一的取值)。但是这个字段只是浏览器约定俗成的实现，并没有确切规范，因此缺乏可靠性。它应该只作为一个兼容字段出现，在当前的网络环境下其实用处已经很小。
总结一下，自从 HTTP/1.1 开始，Expires 逐渐被 Cache-control 取代。Cache-control 是一个相对时间，即使客户端时间发生改变，相对时间也不会随之改变，这样可以保持服务器和客户端的时间一致性。而且 Cache-control 的可配置性比较强大。
Cache-control 的优先级高于 Expires，为了兼容 HTTP/1.0 和 HTTP/1.1，实际项目中两个字段我们都会设置。
当强制缓存失效(超过规定时间)时，就需要使用对比缓存，由服务器决定缓存内容是否失效。
流程上说，浏览器先请求缓存数据库，返回一个缓存标识。之后浏览器拿这个标识和服务器通讯。如果缓存未失效，则返回 HTTP 状态码 304 表示继续使用，于是客户端继续使用缓存；如果失效，则返回新的数据和缓存规则，浏览器响应数据后，再把规则写入到缓存数据库。
但如果是 304 的话，返回的仅仅是一个状态码而已，并没有实际的文件内容，因此 在响应体体积上的节省是它的优化点。它的优化覆盖了文章开头提到过的请求数据的三个步骤中的最后一个：“响应”。通过减少响应体体积，来缩短网络传输时间。所以和强制缓存相比提升幅度较小，但总比没有缓存好。
对比缓存是可以和强制缓存一起使用的，作为在强制缓存失效后的一种后备方案。实际项目中他们也的确经常一同出现。
对比缓存有 2 组字段(不是两个)：
但是他还是有一定缺陷的：
为了解决上述问题，出现了一组新的字段 Etag 和 If-None-Match
Etag 存储的是文件的特殊标识(一般都是 hash 生成的)，服务器存储着文件的 Etag 字段。之后的流程和 Last-Modified 一致，只是 Last-Modified 字段和它所表示的更新时间改变成了 Etag 字段和它所表示的文件 hash，把 If-Modified-Since 变成了 If-None-Match。服务器同样进行比较，命中返回 304, 不命中返回新资源和 200。
Etag 的优先级高于 Last-Modified
当浏览器要请求资源时
总体来说，如上面原理所述，no-cache 从语义上表示下次请求不要直接使用缓存而需要比对，并不对本次请求进行限制。因此浏览器在处理当前页面时，可以放心使用缓存。
当把服务器响应设置为 Cache-Control: no-store 时，情况发生了变化，三种资源都被请求了 2 次。而图片因为还多一次异步请求，总计 3 次。(红框中的都是那一次异步请求)
这同样说明：
所谓浏览器的行为，指的就是用户在浏览器如何操作时，会触发怎样的缓存策略。主要有 3 种：
了解了缓存的原理，我们可能更加关心如何在实际项目中使用它们，才能更好的让用户缩短加载时间，节约流量等。这里有几个常用的模式，供大家参考
Cache-Control: max-age=31536000通常在处理这类资源资源时，给它们的 Cache-Control 配置一个很大的 max-age=31536000 (一年)，这样浏览器之后请求相同的 URL 会命中强制缓存。而为了解决更新的问题，就需要在文件名(或者路径)中添加 hash， 版本号等动态字符，之后更改动态字符，达到更改引用 URL 的目的，从而让之前的强制缓存失效 (其实并未立即失效，只是不再使用了而已)。
在线提供的类库 (如 jquery-3.3.1.min.js, lodash.min.js 等) 均采用这个模式。如果配置中还增加 public 的话，CDN 也可以缓存起来，效果拔群。
这个模式的一个变体是在引用 URL 后面添加参数 (例如 ?v=xxx 或者 ?_=xxx)，这样就不必在文件名或者路径中包含动态参数，满足某些完美主义者的喜好。在项目每次构建时，更新额外的参数 (例如设置为构建时的当前时间)，则能保证每次构建后总能让浏览器请求最新的内容。
特别注意： 在处理 Service Worker 时，对待 sw-register.js(注册 Service Worker) 和 serviceWorker.js (Service Worker 本身) 需要格外的谨慎。如果这两个文件也使用这种模式，你必须多多考虑日后可能的更新及对策。
Cache-Control: no-cache这里的资源不单单指静态资源，也可能是网页资源，例如博客文章。这类资源的特点是：URL 不能变化，但内容可以(且经常)变化。我们可以设置 Cache-Control: no-cache 来迫使浏览器每次请求都必须找服务器验证资源是否有效。
既然提到了验证，就必须 ETag 或者 Last-Modified 出场。这些字段都会由专门处理静态资源的常用类库(例如 koa-static)自动添加，无需开发者过多关心。
也正如上文中提到协商缓存那样，这种模式下，节省的并不是请求数，而是请求体的大小。所以它的优化效果不如模式 1 来的显著。
Cache-Control: max-age=600, must-revalidate不知道是否有开发者从模式 1 和 2 获得一些启发：模式 2 中，设置了 no-cache，相当于 max-age=0, must-revalidate。我的应用时效性没有那么强，但又不想做过于长久的强制缓存，我能不能配置例如 max-age=600, must-revalidate 这样折中的设置呢？
表面上看这很美好：资源可以缓存 10 分钟，10 分钟内读取缓存，10 分钟后和服务器进行一次验证，集两种模式之大成，但实际线上暗存风险。因为上面提过，浏览器的缓存有自动清理机制，开发者并不能控制。
举个例子：当我们有 3 种资源： index.html, index.js, index.css。我们对这 3 者进行上述配置之后，假设在某次访问时，index.js 已经被缓存清理而不存在，但 index.html, index.css 仍然存在于缓存中。这时候浏览器会向服务器请求新的 index.js，然后配上老的 index.html, index.css 展现给用户。这其中的风险显而易见：不同版本的资源组合在一起，报错是极有可能的结局。
除了自动清理引发问题，不同资源的请求时间不同也能导致问题。例如 A 页面请求的是 A.js 和 all.css，而 B 页面是 B.js 和 all.css。如果我们以 A -> B 的顺序访问页面，势必导致 all.css 的缓存时间早于 B.js。那么以后访问 B 页面就同样存在资源版本失配的隐患。
这个问题涉及几个小点
结论是没有区别。在列出 max-age 了之后，must-revalidate 是否列出效果相同，浏览器都会在超过 max-age 之后进行校验，验证缓存是否可用。
在 HTTP 的规范中，只阐述了 must-revalidate 的作用，却没有阐述不列出 must-revalidate 时，浏览器应该如何解决缓存过期的问题，因此这其实是浏览器实现时的自主决策。（可能有少数浏览器选择在源站点无法访问时继续使用过期缓存，但这取决于浏览器自身）
是的。问题的出现和是否列出 'must-revalidate' 无关，依然会存在 JS CSS等文件版本失配的问题。因此常规的网站在不同页面需要使用不同的 JS CSS 文件时，如果要使用 max-age 做强缓存，不要设置一个太短的时间。
既然版本存在失配的问题，那么要避开这个问题，就有两种方法。
第一，整站都使用相同的 JS 和 CSS，即合并后的文件。这个比较适合小型站点，否则可能过于冗余，影响性能。（不过可能还是会因为浏览器自身的清理策略被清理，依然有隐患）
第二，资源是独立使用的，并不需要和其他文件配合生效。例如 RSS 就归在此类。
*请认真填写需求信息，我们会在24小时内与您取得联系。
