HTTP 缓存相关

网络中数据传输是很耗时的，数据要在漫长的路径中奔波，客户端在数据完整到达前只能等待。如果能够复用已经请求过的资源，势必会让整个页面加载高效许多。这可以通过合理地设置服务器的缓存，与浏览器的缓存机制配合以达到最优。

缓存设置得当不但可减少用户等待时间，提升体验，还节省服务器开销省流量带宽。

缓存的配置有两种策略：

• 稳定的内容 + 长期缓存
• 经常变动的内容 + 使用前询问

稳定的内容 + 长期缓存

在知道文件内容不太可能变化的情况下，可对该资源进行长期缓存。

Cache-Control: max-age=31536000

这种模式下浏览器获取资源流程如下：

1. 页面：请求资源 a.v1.js,b.v1.css。
2. 缓存：本地没有，向服务器获取。
3. 服务器：找到资源并返回，同时告知浏览器缓存该资源，比如，缓存一年。
4. 页面：一段时间后再次请求 a.v2.js,b.v1.css。
5. 缓存：发现本地有对 b.v1.css 的缓存，直接使用，对于 a.v2.js 则询问服务器。
6. 服务器：找到资源并返回 a.v2.js，同时告知浏览器缓存该资源。

可以看到，这种模式下，我们更新的是文件名，即资源的 URI 地址，而不是直接更新文件内容。因为文件被缓存后，如果文件名没变，浏览器是不会重新去获取的。

经常变动的内容 + 使用前询问

对于经常变动的资源，但地址又不能变，比如静态博客页面，则不能像上面那样缓存。这种情况下可设置缓存为 no-cache。

Cache-Control: no-cache

需要注意的是，缓存 Header 的值不能按照字面意思来解释，需要去理解它，比如：

• no-cache 并不是表示不要缓存，而是缓存该资源，但使用前先询问服务器该资源是否有更新，而 no-store 才表示完全不缓存。
• must-revalidate 不是必需重新验证资源有效性的意思，而是暗含了一个前提，就是资源如果还没有超过设置的缓存时限 max-age 才重新验证。

此模式下，服务器可通过下发 ETag 或 Last-Modified 响应头，浏览器下次再请求时会查检查已缓存的资源，并带上相应的 If-None-Match 或 If-Modified-Since 请求头，然后服务器再决定是否返回新的资源或告知浏览器直接使用本地缓存。

使用 ETag 的场景示例：

1. 浏览器请求资源。
2. 服务器返回资源，并且带上 ETag （可以是 hash 或者其他能够跟随资源内容而变的 id）。
3. 过段时间，浏览器再次请求该资源，通过设置 If-None-Match 请求头带上前面得到的 ETag。
4. 服务器将 ETag 与资源内容进行比较，发现资源没有更新过，返回 304 （not modified）告诉浏览器资源没有变化，可使用本地已经缓存的版本。
5. 浏览器得到 304 响应，直接使用本地缓存。

整个过程没有对资源进行重复下载。

ETag/Last-Modified 不可用的情况下，服务器始终下发完整资源。

相比方式一，这种方式始终会和服务器进行一次沟通。

max-age 的注意事项

对易变的内容设置 max-age 方式的缓存容易引起各资源不一致的问题。


比如设置缓存为如下格式时，

Cache-Control: must-revalidate, max-age=600

对于缓存时间小于 10 分钟的资源，浏览器不会重新请求而是直接使用缓存。

假设一个场景，页面 A 包含一个公共脚本 common.js 和页面 A 的业务脚本 a.js。当页面 A 首页加载时，所有资源都正确缓存。

过了一段时间，切换到页面 B，页面 B 也包含公共脚本 common.js，同时有自己的业务脚本 b.js。

在请求页面 B 之前，因为已经缓存过 common.js，所以会使用缓存，但这期间文件有可能已经更新。此时浏览器使用旧的 common.js 运行页面 B 势必会出问题。

所以，对于经常变动的内容设置 max-age 是不推荐的做法。

多数情况下针对上面的问题，一次强刷就解决了，这也是有 bug 时研发会给出的高频回复。

参考内容

• Caching best practices & max-age gotchas
• HTTP Caching