学会这篇就够了，彻底弄懂前端缓存

发表于 3年以前 | 总阅读数：403 次

前端缓存

前端缓存，这是一个老生常谈的话题，也常被作为前端面试的一个知识点。今天我们再来总结一下。

扩展

缓存失效问题

引入了缓存固然是好事，能大大提升响应速度以及减轻服务端的压力，但是也会出现一些问题，比如我们明明更新了系统版本，为什么客户端看到的还是老文件。在不同的时代有不同的解决方案。

老方案

老方案通过人工自己修改文件名或者在文件名后带上版本号、时间戳，这样客户端就会当新文件请求并使用，之前的强缓存就算在有效期内也会失效。

<script src="http://randy.js?version=1.1.1> </script>
复制代码

新方案

在现在的构建阶段基本上都不需要人工操作了，都是使用构建工具比如Wbpack、Gulp、Grunt等构建工具自动构建。比如在使用Webpack构建的时候，会根据文件名或文件内容自动计算hash值来给文件命名，当内容或文件名发生改变的时候，构建出来的文件名也一定会不一样，这样也解决了强缓存还在有效期内的问题。

pragma

pragma是旧产物，已经逐步抛弃，有些网站为了向下兼容还保留了这个字段。pragma的值为no-cache时，表示禁用缓存。优先级是 pragma > cache-control > expires。

流程图

有了这张流程图，可以让你们理解的更清楚。

缓存的配置

如果我们使用Nginx作为Web服务器，我们可以如下配置

location / {

  # 其它配置
  ...

  if ($request_uri ~* .*[.](js|css|map|jpg|png|svg|ico)$) {
    #非html缓存1个月
    add_header Cache-Control "public, max-age=2592000";
  }

  if ($request_filename ~* ^.*[.](html|htm)$) {
    #html文件使用协商缓存
    add_header Cache-Control "public, no-cache";
  }
}

复制代码

缓存到底存在哪？

很多小伙伴会好奇，这缓存到底存在哪里了呢？别急，我们接着往下讲。

按缓存位置分类我们可以分为memory cache、disk cache、Service Worker三类，我们可以在 Chrome 的开发者工具中，Network -> Size 一列看到一个请求最终的处理方式：如果是大小 (多少 K，多少 M 等) 就表示是网络请求，否则会列出 from memory cache、from disk cache、from ServiceWorker就表示命中了缓存。

memory cache 是内存中的缓存，(与之相对 disk cache 就是硬盘上的缓存)。按照操作系统的常理：先读内存，再读硬盘。

微信截图_20220119110918.png

disk cache 也叫 HTTP cache，顾名思义是存储在硬盘上的缓存，因此它是持久存储的，是实际存在于文件系统中的。而且它允许相同的资源在跨会话，甚至跨站点的情况下使用，例如两个站点都使用了同一张图片。

微信截图_20220119110855.png

上述的缓存策略以及缓存/读取/失效的动作都是由浏览器内部判断进行的，我们只能设置响应头的某些字段来告诉浏览器，而不能自己操作。service work给予了我们另外一种更加灵活，可以直接的操作方式。我们可以从 Chrome 的 Application找到Service Workers。这个缓存是永久性的，即关闭 TAB 或者浏览器，下次打开依然还在(而 memory cache 不是)。有两种情况会导致这个缓存中的资源被清除：手动调用 API cache.delete(resource) 或者容量超过限制，被浏览器全部清空。