关于浏览器缓存的问题
1、缓存的作用
对于一个数据请求来说，可以分为发起网络请求、后端处理、浏览器响应三个步骤。浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求，或者发起了请求但后端存储的数据和前端一致，那么就没有必要再将数据回传回来，这样就减少了响应数据。
2、浏览器缓存的位置
从缓存位置上来说分为四种，并且各自有优先级，当依次查找缓存且都没有命中的时候，才会去请求网络。
- Service Worker
- Memory Cache（内存缓存）
- Disk Cache（硬盘缓存）
- Push Cache
如果以上四种缓存都没有命中的话，那么只能发起请求来获取资源了。
2.1、Service Worker
Service Worker：Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker的话，传输协议必须为 HTTPS。
Service Worker 的缓存与浏览器其他内建的缓存机制不同，它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。
2.2、Memory Cache（内存缓存）
2.3、Disk Cache（硬盘缓存）
Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。
在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP Herder 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。绝大部分的缓存都来自 Disk Cache。
浏览器会把哪些文件丢进内存中？哪些丢进硬盘中？ 关于这点，网上说法不一，不过以下观点比较靠得住：
- 对于大文件来说，大概率是不存储在内存中的，反之优先
- 当前系统内存使用率高的话，文件优先存储进硬盘
2.4、Push Cache
3、缓存策略
那么为了性能上的考虑，大部分的接口都应该选择好缓存策略，通常浏览器缓存策略分为两种：强缓存和协商缓存，并且缓存策略都是通过设置 HTTP Header 来实现的。
强制缓存优先于协商缓存进行。若强制缓存(Expires和Cache-Control)生效则直接使用缓存，若不生效则进行协商缓存（Last-Modified / If-Modified-Since和Etag / If-None-Match）。协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，请求响应码返回200，重新返回资源和缓存标识，再存入浏览器缓存中；生效则返回304，继续使用缓存。
优先级：
Cache-Control > expires > Etag > Last-Modified
| 缓存类型 | 获取资源形式 | 状态码 | 是否发送请求到服务器 |
| 强制缓存 | 从缓存取 | 200（from cache） | 否，直接从缓存取 |
| 协商缓存 | 从缓存取 | 304（Not Modified） | 是，通过服务器来告知缓存是否可用 |
3.1、浏览器缓存策略
由上图我们可以知道：
-
浏览器每次发起请求，都会先在浏览器缓存中查找该请求的结果以及缓存标识
-
浏览器每次拿到返回的请求结果都会将该结果和缓存标识存入浏览器缓存中
以上两点结论就是浏览器缓存机制的关键，它确保了每个请求的缓存存入与读取。
3.1.1、缓存机制流程图
强制缓存优先于协商缓存进行，若强制缓存(Expires和Cache-Control)生效则直接使用缓存，若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，返回200，重新返回资源和缓存标识，再存入浏览器缓存中；生效则返回304，继续使用缓存。具体流程图如下：
如果什么缓存策略都没设置，那么浏览器会怎么处理？对于这种情况，浏览器会采用一个启发式的算法，通常会取响应头中的 Date 减去 Last-Modified 值的 10% 作为缓存时间。
4、强缓存（不会发起请求，直接命中缓存）
强缓存：不会向服务器发送请求，直接从缓存中读取资源。
在 Chrome 中强缓存的请求状态码返回是 200，并且 Size 显示 from disk cache 或 from memory cache 。而在 Fire Fox中，from cache 状态码是 304，不同浏览器的策略可能有些许不同。
Chrome 浏览器强制缓存示例如下：
强缓存可以通过设置两种 HTTP Header 实现：Expires 和 Cache-Control。两者同时存在的话，Cache-Control优先级高于Expires。强缓存判断是否缓存的依据来自于是否超出某个时间或者某个时间段，而不关心服务器端文件是否已经更新，所以就可能会导致加载文件不是服务器端最新的内容。
4.1、Expires
缓存过期时间，用来指定资源到期的时间，是服务器端的具体的时间点。也就是说，Expires=max-age + 请求时间，需要和Last-modified结合使用。Expires是Web服务器响应消息头字段，在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求。
Expires 是 HTTP/1 的产物，受限于本地时间，如果修改了本地时间，可能会造成缓存失效。比如：Expires: Wed, 22 Oct 2018 08:41:00 GMT表示资源会在 Wed, 22 Oct 2018 08:41:00 GMT 后过期，需要再次请求。
Expires 是 http 1.0 的规范，值是一个GMT 格式的时间点字符串，比如 Expires:Mon,18 Oct 2066 23:59:59 GMT 。这个时间点代表资源失效的时间，如果当前的时间戳在这个时间之前，则判定命中缓存。有一个缺点是，失效时间是一个绝对时间，如果服务器时间与客户端时间偏差较大时，就会导致缓存混乱。而服务器的时间跟用户的实际时间是不一样是很正常的，所以 Expires 在实际使用中会带来一些麻烦。
4.2、Cache-Control
在HTTP/1.1中，Cache-Control是最重要的规则，主要用于控制网页缓存。比如当Cache-Control:max-age=300时，则代表在这个请求正确返回时间（浏览器也会记录下来）的5分钟内再次加载资源，就会命中强缓存。如果 Cache-Control与 Expires 同时存在的话， Cache-Control 的优先级高于 Expires 。
Cache-Control这个字段是 http 1.1 的规范，一般常用该字段的 max-age 值来进行判断，它是一个相对时间，比如 .Cache-Control:max-age=3600 代表资源的有效期是 3600 秒。并且返回头中的 Date 表示消息发送的时间，表示当前资源在 Date ~ Date +3600s 这段时间里都是有效的。不过我在实际使用中常常遇到设置了 max-age 之后，在 max-age 时间内重新访问资源却会返回 304 not modified ，这是由于服务器的时间与本地的时间不同造成的。
Cache-Control 可以在请求头或者响应头中设置，并且可以组合使用多种指令：
- public：所有内容都将被缓存（客户端和代理服务器都可缓存）。具体来说响应可被任何中间节点缓存，如 Browser <-- proxy1 <-- proxy2 <-- Server，中间的proxy可以缓存资源，比如下次再请求同一资源proxy1直接把自己缓存的东西给 Browser 而不再向proxy2要。
- private：所有内容只有客户端可以缓存，中间节点不允许缓存。Cache-Control的默认取值。具体来说，对于Browser <-- proxy1 <-- proxy2 <-- Server，proxy 会老老实实把Server 返回的数据发送给proxy1，自己不缓存任何数据。当下次Browser再次请求时proxy会做好请求转发而不是自作主张给自己缓存的数据。
- no-cache：客户端缓存内容，是否使用缓存则需要经过协商缓存来验证决定。表示不使用 Cache-Control的缓存控制方式做前置验证，而是使用 Etag 或者Last-Modified字段来控制缓存。需要注意的是，no-cache这个名字有一点误导。设置了no-cache之后，并不是说浏览器就不再缓存数据，只是浏览器在使用缓存数据时，需要先确认一下数据是否还跟服务器保持一致。
- no-store：所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存
- max-age：max-age=xxx (xxx is numeric)表示缓存内容将在xxx秒后失效
- s-maxage（单位为s)：同max-age作用一样，只在代理服务器中生效（比如CDN缓存）。比如当s-maxage=60时，在这60秒中，即使更新了CDN的内容，浏览器也不会进行请求。max-age用于普通缓存，而s-maxage用于代理缓存。s-maxage的优先级高于max-age。如果存在s-maxage，则会覆盖掉max-age和Expires header。
- max-stale：能容忍的最大过期时间。max-stale指令标示了客户端愿意接收一个已经过期了的响应。如果指定了max-stale的值，则最大容忍时间为对应的秒数。如果没有指定，那么说明浏览器愿意接收任何age的响应（age表示响应由源站生成或确认的时间与当前时间的差值）。
- min-fresh：能够容忍的最小新鲜度。min-fresh标示了客户端不愿意接受新鲜度不多于当前的age加上min-fresh设定的时间之和的响应。
从图中我们可以看到，我们可以将多个指令配合起来一起使用，达到多个目的。比如说我们希望资源能被缓存下来，并且是客户端和代理服务器都能缓存，还能设置缓存失效时间等等。
4.2.1、Expires和Cache-Control的区别
其实这两者差别不大，区别就在于 Expires 是http1.0的产物，Cache-Control是http1.1的产物，两者同时存在的话，Cache-Control优先级高于Expires；在某些不支持HTTP1.1的环境下，Expires就会发挥用处。所以Expires其实是过时的产物，现阶段它的存在只是一种兼容性的写法。
5、协商缓存（会重新发起请求，由服务器决定是否使用缓存）
强缓存判断是否缓存的依据来自于是否超出某个时间或者某个时间段，而不关心服务器端文件是否已经更新，这可能会导致加载文件不是服务器端最新的内容。此时我们可以使用协商缓存策略。
协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程。协商缓存可以通过设置两种 HTTP Header 实现：Last-Modified 和 ETag 。服务器校验优先考虑Etag。
协商缓存时请求的响应状态码是 304，示例如下：
协商缓存生效和失效的请求过程示意图：
- 协商缓存失效，返回 304 和 Not Modified：
- 协商缓存失效，返回200和请求结果：
5.1、Last-Modified（If-Modified-Since）
浏览器在第一次访问资源时，服务器在返回资源的同时，会自动在 response header 中添加 Last-Modified 的响应头，值是这个资源在服务器上的最后修改时间，浏览器接收后会将该文件响应头 Last-Modified 缓存起来。
第一次请求：
在浏览器下一次请求该资源时，浏览器检测到有 Last-Modified 这个header，会自动往请求头中添加 If-Modified-Since ，值就是 Last-Modified 中的值：
服务器再次收到这个资源请求时，会自动根据 If-Modified-Since 中的值与服务器中这个资源的最后修改时间对比。如果没有变化，则返回 304 和 空 的响应体，浏览器会直接从缓存读取该资源。如果 If-Modified-Since 的时间小于服务器中这个资源的最后修改时间，说明文件有更新，服务器会返回新的资源文件和 200。
比如我手动修改了服务器中 index.html 文件中的内容，重新刷新浏览器，则结果如下：
可以看到，last-modified 的值自动发生了改变，服务器重新响应了最新的资源。
但是 Last-Modified 存在一些弊端：
- 如果本地打开缓存文件，即使没有对文件进行修改，但还是会造成 Last-Modified 被修改，服务端不能命中缓存导致发送相同的资源
- 因为 Last-Modified 只能以秒计时，如果在不可感知的时间内修改完成文件，那么服务端会认为资源还是命中了，不会返回正确的资源
5.2、ETag（If-None-Match）
根据文件修改时间来决定是否缓存尚有不足，我们可以直接根据文件内容是否修改来决定缓存策略，也就是使用 ETag。
Etag是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)，只要资源有变化，Etag就会重新生成。浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的 Etag 值放到 request header 里的 If-None-Match 里，服务器只需要比较客户端传来的If-None-Match 跟自己服务器上该资源的 ETag 是否一致，就能很好地判断资源相对客户端而言是否被修改过了。如果服务器发现ETag匹配不上，那么直接以常规GET 200 回包形式将新的资源（当然也包括了新的ETag）发给客户端；如果ETag是一致的，则直接返回304知会客户端直接使用本地缓存即可。
5.2.1、Last-Modified和ETag的对比
- 首先在精确度上，Etag要优于Last-Modified。Last-Modified的时间单位是秒，如果某个文件在1秒内改变了多次，那么他们的Last-Modified其实并没有体现出来修改，但是Etag每次都会改变确保了精度；如果是负载均衡的服务器，各个服务器生成的Last-Modified也有可能不一致。
- 第二在性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值。
- 第三在优先级上，服务器校验优先考虑Etag
6、不同场景推荐使用的缓存策略
6.1、频繁变动的资源
对于频繁变动的资源，首先需要使用Cache-Control: no-cache 使浏览器每次都请求服务器，然后配合 ETag 或者 Last-Modified 来验证资源是否有效。这样的做法虽然不能节省请求数量，但是能显著减少响应数据大小。
Cache-Control: no-cache
6.2、不常变化的资源
max-age=31536000 (一年)，这样浏览器之后请求相同的 URL 会命中强制缓存。而为了解决更新的问题，就需要在文件名(或者路径)中添加 hash， 版本号等动态字符，之后更改动态字符，从而达到更改引用 URL 的目的，让之前的强制缓存失效 (其实并未立即失效，只是不再使用了而已)。 在线提供的类库 (如 jquery-3.3.1.min.js, lodash.min.js 等) 均采用这个模式。Cache-Control: max-age=31536000
7、用户行为对浏览器缓存的影响
所谓用户行为对浏览器缓存的影响，指的就是用户在浏览器如何操作时，会触发怎样的缓存策略。
7.1、浏览器中直接输入url（能命中缓存）
打开网页，地址栏输入地址： 能命中缓存。查找 disk cache 中是否有匹配。如有则使用；如没有则发送网络请求。
7.2、普通F5刷新（能命中缓存）
普通刷新 (F5)：能命中缓存。因为 TAB 并没有关闭，因此 memory cache 是可用的，会被优先使用(如果匹配的话)。其次才是 disk cache。
7.3、强制刷新 ctrl+F5（不会命中缓存）
- 强制刷新 (Ctrl + F5)：不会命中缓存，即浏览器不使用缓存。发送的请求头部均带有
Cache-control: no-cache(为了兼容，还带了Pragma: no-cache)，服务器直接返回 200 和最新内容。
