继续创作，加速生长！这是我参加「日新方案 10 月更文应战」的第1天，点击查看活动详情

1. 前言

公司事务群里经常反应某个功能忽然失效了，前端开发儿回复：整理浏览器缓存，从头拜访。客户乖乖地操作后，反应能够运用了！

我也不清楚到底哪里缓存了，缓存了什么，横竖万能的重启/整理缓存真真好使~dog。

今日就一起来扒拉下浏览器缓存究竟怎么回事。

本文运用nodejs开启本地服务，html文件设置一个img标签来拜访图片，研究静态资源缓存。全文案例代码见Github仓库

2. HTTP缓存标头

浏览器缓存设置需求靠HTTP头部控制缓存战略，所以咱们先了解下涉及到的HTTP头部。

正所谓：“工欲善其事，必先利其器”。

2.1 Expires

在HTTP/1.0时经过Expires头部来告知浏览器将资源缓存下来。该值是服务端设置的绝对时刻，告知浏览器资源的过期时刻，即在xx时刻缓存过期，在过期时刻内能够选用本地缓存资源，过期后需求从头恳求服务器获取资源。

因为Expires的值是服务端的绝对时刻，若客户端与服务端时刻不共同，则会导致资源缓存更新不及时或缓存失效问题。因而在HTTP1.1时提出了Cache-Control: max-age=xx头部来替代Expires。

2.2 Cache-Control

在HTTP/1.1时经过Cache-Control头告知浏览器选用缓存，而不同的值对应不同的缓存战略，它能够作为恳求头和呼应头。

Cache-Control值 含义
public 标明呼应能够被任何对象（包括：发送恳求的客户端，署理服务器，等等）缓存，即使是一般不行缓存的内容（例如：1.该呼应没有max-age指令或Expires音讯头；2. 该呼应对应的恳求办法是POST）
private 标明呼应只能被单个用户缓存，不能作为共享缓存（即署理服务器不能缓存它）。私有缓存能够缓存呼应内容
no-cache 在发布缓存副本之前，强制要求缓存把恳求提交给原始服务器进行验证 (洽谈缓存验证)
no-store 缓存不该存储有关客户端恳求或服务器呼应的任何内容，即不运用任何缓存
max-age=5 设置缓存存储的最大周期，超越这个时刻缓存被认为过期 (单位秒)。与Expires相反，时刻是相对于恳求的时刻
s-maxage=5 覆盖max-age或许Expires头，可是仅适用于共享缓存 (比方各个署理)，私有缓存会疏忽它
must-revalidate 一旦资源过期（比方现已超越max-age），在成功向原始服务器验证之前，缓存不能用该资源呼应后续恳求

Cache-Control的全部值可查看MDN Cache-Control

  1. 经过设置max-age的值来替代Expires，时刻是相对于客户端的恳求时刻，即在xx秒后缓存过期。
  2. 这2种缓存战略是属于强缓存，在过期时刻内都选用本地缓存，只有当缓存过期后，才从头恳求服务器。
  3. 假如同时设置了这2个头部字段，会疏忽Expires。
const http = require('http');
const fs = require('fs');
const url = require('url');
http.createServer((req, res) => {
  const {
    pathname
  } = url.parse(req.url)
  if (pathname === '/') {
    const data = fs.readFileSync('./index.html');
    res.end(data);
  } else if (/.*?.jpe?g/.test(pathname)) {
    res.setHeader('Cache-Control', 'max-age=5');
    const data = fs.readFileSync('./images/02.jpeg');
    res.end(data)
  } else {
    res.end('Not Found')
  }
}).listen(8000, () => {
  console.log('服务已在8000端口启动：localhost:8000')
})

在5秒内，改写浏览器重复拜访图片都是复用的本地缓存资源。

再看一次HTTP缓存，下次一定会！

5秒后，图片缓存过期，将从头恳求服务器，改写本地缓存。

因为max-age值单位是秒，若缓存资源在1秒内已更新，则会导致客户端的资源无法及时得到更新，拜访的仍是旧版本资源问题，因而提出了洽谈缓存战略，Cache-Control: no-cache表明选用洽谈缓存，配合一对Last-Modified/If-Modified-Since头优化此问题。

2.3 Last-Modified / If-Modified-Since

服务器经过呼应Last-Modified头告知浏览器将资源缓存起来，客户端需求在下一次拜访资源时恳求服务器，而且带上If-Modified-Since恳求头信息，问问资源是否过期，由服务器呼应经过是否过期，是否需求从头发送资源给客户端。

Last-Modified值是资源修正时刻，由服务器呼应给客户端，下次客户端拜访资源时，带上If-Modified-Since恳求头，值为Last-Modified值。服务器收到客户端恳求时，校验If-Modified-Since值是不是和资源的修正时刻值共同。若共同，则表明资源未过期，回来给客户端304 Not Modified呼应码；若不共同，则表明资源过期，回来更新后的资源给客户端。

if (/.*?.jpe?g/.test(pathname)) {
    // 设置头字段大小写无所谓，浏览器会统一转小写处理，获取头选用全小写
    res.setHeader('Cache-Control', 'no-cache');
    // 获取资源修正时刻
    const stat = fs.statSync('./images/02.jpeg');
    // 设置GMT时刻格局
    const lastModified = stat.mtime.toUTCString();
    res.setHeader('Last-Modified', lastModified);
    // 获取恳求头，判别是否和服务器修正时刻共同
    const ifModifiedSince = req.headers['if-modified-since'];
    if (ifModifiedSince === lastModified) {
      res.writeHead(304, 'Not Modified');
      res.end();
      return;
    }
    const data = fs.readFileSync('./images/02.jpeg');
    res.end(data)
  }

咱们能够经过修正图片名来更新修正时刻，来验证浏览器是否会从头恳求服务器，答案是肯定会从头恳求的，因为服务器的Last-Modified值现已变更，与客户端的If-Modified-Since值已不同。

再看一次HTTP缓存，下次一定会！

因为修正资源姓名也会改写资源的修正时刻，导致资源实际内容未修正浏览器却要从头获取资源，糟蹋网络流量等问题，因而提出了Etag/If-None-Match来优化此问题。

2.4 Etag / If-None-Match

服务器经过呼应Etag头告知浏览器将资源的指纹信息，客户端需求在下一次拜访资源时恳求服务器，而且带上If-None-Match恳求头信息，问问资源是否过期，由服务器呼应资源是否过期，是否需求从头发送资源给客户端。

Etag值是依据资源的二进制数据核算出来的hash值，因而资源有变化则Etag值也会更新，由服务器呼应给客户端，下次客户端拜访资源时，需求带上If-None-Match恳求头，值为Etag值。服务器收到客户端恳求时，校验If-None-Match恳求头的值是不是和服务器上资源的指纹共同。若共同，则表明资源未过期，回来给客户端304 Not Modified呼应码；若不共同，则表明资源过期，回来更新后的资源给客户端。

if (/.*?.jpe?g/.test(pathname)) {
    res.setHeader('Cache-Control', 'no-cache');
    // 测试运用第3方etag包来核算资源的hash值。其实这儿测试，能够手动设置etag值，例如res.setHeader('Etag', ‘1234’);
    const etagContent = etag(data);
    res.setHeader('Etag', etagContent);
    const ifNoneMatch = req.headers['if-none-match'];
    if (ifNoneMatch === etagContent) {
      res.writeHead(304, 'Not Modified');
      res.end();
      return;
    }
    const data = fs.readFileSync('./images/02.jpeg');
    res.end(data)
  }

第2次拜访时，Etag / If-None-Match值共同，服务器直接回来304，告知浏览器选用缓存。

再看一次HTTP缓存，下次一定会！

假如咱们将资源内容进行更改，浏览器再次拜访图片时，服务器会从头回来资源，并改写客户端缓存。

当Last-Modified与Etag同时存在时，优先选用Etag，因为Etag判别资源是否过期更精准。

因为Etag是依据资源核算而来，假如资源较大，而且每次条件恳求时都要核算Etag值，也是一个不小的开销，因而咱们在实际开发中依据不同资源，设置不同的缓存战略。

3. 缓存战略

  1. Cache-Control: max-age=0; 表明资源立刻过期，作用和设置no-cache共同，然后选用洽谈缓存。
  2. Cache-Control: no-cache; Last-Modified与Etag同时存在的状况，依据Etag优先准则。可是假如服务器没有清晰呼应缓存方式，则会激活浏览器启发式缓存。
  3. 若浏览器强制改写或许在控制台☑️禁用缓存，则浏览器会自动在恳求头添加Cache-Control: no-cache和Pragma: no-cache，标明应向服务器恳求资源。

Pragma是一个在 HTTP/1.0 中规定的通用首部，这个首部的作用依赖于不同的实现，所以在“恳求 – 呼应”链中或许会有不同的作用。它用来向后兼容只支撑 HTTP/1.0 协议的缓存服务器，那时候 HTTP/1.1 协议中的 Cache-Control 还没有出来。

再看一次HTTP缓存，下次一定会！

4. 启发式缓存

假如一个能够缓存的恳求没有设置Expires / Cache-Control，可是呼应头有设置Last-Modified标头，这种状况下浏览器会有一个默许的缓存战略：(当前时刻 - Last-Modified)*0.1，在此期间浏览器会一向重用本地缓存，这便是启发式缓存。

再看一次HTTP缓存，下次一定会！

启发式缓存是在Cache-Control被广泛选用之前呈现的一种解决办法，基本上所有呼应都应清晰指定Cache-Control标头。否则会导致客户端在一定时刻内选用本地缓存，而服务器无计可施，只能要求客户手动整理浏览器缓存或许等候缓存过期。

5. 最佳实践

运用前端框架开发的项目，默许打包项目生成的js，css等资源文件，在每次打包时会核算hash值作为文件名，像这种咱们能够确定的资源能够设置一个较长时刻的强缓存，毕竟每次打包后文件名不共同客户端会当作新资源恳求服务器，能够防止洽谈缓存恳求服务器的步骤。

6. 缓存流程图

graph TD
A(拜访资源) --> B(是否射中缓存)
B --> |是| C(强缓存是否过期)
B --> |否| D(服务器回来200和资源实体)
C --> |未过期| E(重用本地缓存)
C --> |已过期/不存在洽谈缓存| F(洽谈缓存是否过期)
F --> |未过期| H(服务器回来304选用本地缓存)
F --> |已过期| D