共计 3319 个字符，预计需要花费 9 分钟才能阅读完成。
之前一直对浏览器缓存只能描述一个大概，深层次的原理不能描述上来；终于在前端的两次面试过程中被问倒下，为了泄恨，查阅一些资料最终对其有了一个更深入的理解，废话不多说，赶紧来看看浏览器缓存的那些事吧，有不对的地方，请各位不吝赐教啊。
本文主要讲解浏览器端的缓存，缓存的作用是不言而喻的，能够极大的改善网页性能，提高用户体验。
1、浏览器缓存缓存这东西，第一次必须获取到资源后，然后根据返回的信息来告诉如何缓存资源，可能采用的是强缓存，也可能告诉客户端浏览器是协商缓存，这都需要根据响应的 header 内容来决定的。下面用两幅图来描述浏览器的缓存是怎么玩的，让大家有个大概的认知。
浏览器第一次请求时：
浏览器后续在进行请求时：
从上图可以知道，浏览器缓存包含两种类型，即强缓存（也叫本地缓存）和协商缓存，浏览器在第一次请求发生后，再次请求时：
浏览器在请求某一资源时，会先获取该资源缓存的 header 信息，判断是否命中强缓存（cache-control 和 expires 信息），若命中直接从缓存中获取资源信息，包括缓存 header 信息；本次请求根本就不会与服务器进行通信；在 firebug 下可以查看某个具有强缓存资源返回的信息，例如本地 firebug 查看的一个强缓存 js 文件
如果没有命中强缓存，浏览器会发送请求到服务器，请求会携带第一次请求返回的有关缓存的 header 字段信息（Last-Modified/If-Modified-Since 和 Etag/If-None-Match），由服务器根据请求中的相关 header 信息来比对结果是否协商缓存命中；若命中，则服务器返回新的响应 header 信息更新缓存中的对应 header 信息，但是并不返回资源内容，它会告知浏览器可以直接从缓存获取；否则返回最新的资源内容强缓存与协商缓存的区别，可以用下表来进行描述：
获取资源形式 状态码 发送请求到服务器
强缓存 从缓存取 200（from cache）否，直接从缓存取协商缓存 从缓存取 304（not modified）是，正如其名，通过服务器来告知缓存是否可用
2、强缓存相关的 header 字段强缓存上面已经介绍了，直接从缓存中获取资源而不经过服务器；与强缓存相关的 header 字段有两个：
expires，这是 http1.0 时的规范；它的值为一个绝对时间的 GMT 格式的时间字符串，如 Mon, 10 Jun 2015 21:31:12 GMT，如果发送请求的时间在 expires 之前，那么本地缓存始终有效，否则就会发送请求到服务器来获取资源
cache-control：max-age=number，这是 http1.1 时出现的 header 信息，主要是利用该字段的 max-age 值来进行判断，它是一个相对值；资源第一次的请求时间和 Cache-Control 设定的有效期，计算出一个资源过期时间，再拿这个过期时间跟当前的请求时间比较，如果请求时间在过期时间之前，就能命中缓存，否则就不行；cache-control 除了该字段外，还有下面几个比较常用的设置值：
no-cache：不使用本地缓存。需要使用缓存协商，先与服务器确认返回的响应是否被更改，如果之前的响应中存在 ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。
no-store：直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
public：可以被所有的用户缓存，包括终端用户和 CDN 等中间代理服务器。
private：只能被终端用户的浏览器缓存，不允许 CDN 等中继缓存服务器对其缓存。注意：如果 cache-control 与 expires 同时存在的话，cache-control 的优先级高于 expires
3、协商缓存相关的 header 字段协商缓存都是由服务器来确定缓存资源是否可用的，所以客户端与服务器端要通过某种标识来进行通信，从而让服务器判断请求资源是否可以缓存访问，这主要涉及到下面两组 header 字段，这两组搭档都是成对出现的，即第一次请求的响应头带上某个字段（Last-Modified 或者 Etag），则后续请求则会带上对应的请求字段（If-Modified-Since 或者 If-None-Match），若响应头没有 Last-Modified 或者 Etag 字段，则请求头也不会有对应的字段。
Last-Modified/If-Modified-Since 二者的值都是 GMT 格式的时间字符串，具体过程：浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在 respone 的 header 加上 Last-Modified 的 header，这个 header 表示这个资源在服务器上的最后修改时间
浏览器再次跟服务器请求这个资源时，在 request 的 header 上加上 If-Modified-Since 的 header，这个 header 的值就是上一次请求时返回的 Last-Modified 的值
服务器再次收到资源请求时，根据浏览器传过来 If-Modified-Since 和资源在服务器上的最后修改时间判断资源是否有变化，如果没有变化则返回 304 Not Modified，但是不会返回资源内容；如果有变化，就正常返回资源内容。当服务器返回 304 Not Modified 的响应时，response header 中不会再添加 Last-Modified 的 header，因为既然资源没有变化，那么 Last-Modified 也就不会改变，这是服务器返回 304 时的 response header
浏览器收到 304 的响应后，就会从缓存中加载资源
如果协商缓存没有命中，浏览器直接从服务器加载资源时，Last-Modified 的 Header 在重新加载的时候会被更新，下次请求时，If-Modified-Since 会启用上次返回的 Last-Modified 值
Etag/If-None-Match 这两个值是由服务器生成的每个资源的唯一标识字符串，只要资源有变化就这个值就会改变；其判断过程与 Last-Modified/If-Modified-Since 类似，与 Last-Modified 不一样的是，当服务器返回 304 Not Modified 的响应时，由于 ETag 重新生成过，response header 中还会把这个 ETag 返回，即使这个 ETag 跟之前的没有变化。
4、既生 Last-Modified 何生 Etag 你可能会觉得使用 Last-Modified 已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要 Etag 呢？HTTP1.1 中 Etag 的出现主要是为了解决几个 Last-Modified 比较难解决的问题：一些文件也许会周期性的更改，但是他的内容并不改变 (仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新 GET；
某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说 1s 内修改了 N 次)，If-Modified-Since 能检查到的粒度是 s 级的，这种修改无法判断 (或者说 UNIX 记录 MTIME 只能精确到秒)；
某些服务器不能精确的得到文件的最后修改时间。
这时，利用 Etag 能够更加准确的控制缓存，因为 Etag 是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符。
Last-Modified 与 ETag 是可以一起使用的，服务器会优先验证 ETag，一致的情况下，才会继续比对 Last-Modified，最后才决定是否返回 304。
5、用户的行为对缓存的影响盗用网上的一张图，基本能描述用户行为对缓存的影响
6、强缓存如何重新加载缓存缓存过的资源上面说到，使用强缓存时，浏览器不会发送请求到服务端，根据设置的缓存时间浏览器一直从缓存中获取资源，在这期间若资源产生了变化，浏览器就在缓存期内就一直得不到最新的资源，那么如何防止这种事情发生呢？
通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。
类似下图所示：
这样每次文件改变后就会生成新的 query 值，这样 query 值不同，也就是页面引用的资源路径不同了，之前缓存过的资源就被浏览器忽略了，因为资源请求的路径变了。
