前端缓存——浏览器缓存

---

缓存获取顺序

1. 浏览器会率先查找内存缓存，如果资源在内存中存在，那么直接从内存中加载
2. 如果内存中没找到，接下去会去磁盘中查找，找到便从磁盘中获取
3. 如果磁盘中也没有找到，那么就进行网络请求，并将请求后符合条件的资源存入内存和磁盘中

按照缓存位置划分

Service Worker Cache

- 概念

Service Worker 本质上是一种用 JavaScript 编写的脚本，其作为一个独立的线程，它可以使应用程序能够控制网络请求，缓存这些请求以提高性能，并提供对缓存内容的离线访问。

Service Worker 依赖两个 API 使应用程序离线工作：Cache（应用程序数据的持久性内容存储）和 Fetch（一种从网络检索内容的标准方法）

Service Worker 缓存是持久的，独立于浏览器缓存或网络状态

- 生命周期与缓存

生命周期包括：注册、安装、激活
缓存：采用缓存回退网络的方式进行代码的编写，即拦截请求时如果缓存中存在该资源则直接获取，否则再向服务端请求资源并进行缓存

- 兼容性

在不支持 Service Worker 的低版本浏览器中，我们可能仍然需要进行一些兼容处理，使用户可以使用其主要功能

同时出于安全考虑，Service worker 只能在 https 及 localhost 下被使用

Memory Cache（内存缓存）

优点：速度快、优先级高，从内存中获取资源耗时为 0 ms
缺点：生命周期短，当网页关闭后内存就会释放，受限制于计算机内存的大小

Disk Cache（磁盘缓存）

优点：生命周期长，不触发删除操作则一直存在
缺点：获取资源的速度相对内存缓存较慢

注意：Disk Cache 会根据保存下来的资源的 HTTP 首部字段来判断它们是否需要重新请求，如果重新请求那便是强缓存的失效流程，否则便是生效流程

存储型缓存

Cookie

Cookie 的存储空间很小，不能超过 4KB，因此这一缺点也限制了它用于存储较大容量数据的能力

- 客户端存储 token 信息的方式有两种

1. 服务端自动植入
   服务端登录接口可以在返回前端的响应报头中设置首部字段 set-cookie 来将 token 信息植入浏览器 cookie 中，之后前端调用任何同域下的接口时，浏览器会自动将网站的 cookie 值附加在请求头中传给后端进行校验，前端则不需要关心 token 的存取问题
2. 前端手动存储
   服务端登录接口成功后直接将用户的 token 信息通过响应实体的方式返回给前端。前端获取到 token 信息后可以通过前端存储方法将数据持久化缓存起来，并在退出后手动清除。同时在调用后端接口时需要手动将 token 传递给服务端

Web Storage

• Session Storage

Session Storage 作为临时性的本地存储，其生命周期存在于网页会话期间，即使用 Session Storage 存储的缓存数据在网页关闭后会自动释放，并不是持久性的

• Local Storage

Local Storage 则存储于浏览器本地，除非手动删除或过期，否则其一直存在，属于持久性缓存

IndexedDB

通过使用 Web Storage，我们实现了网页间数据的临时和持久化存储，但和大容量的数据库相比 Web Storage 存储的空间还是相对有限，此时最终的解决方案便是 —— IndexedDB

IndexedDB 是一个大规模的 NoSQL 存储系统，它几乎可以存储浏览器中的任何数据内容，包括二进制数据（ArrayBuffer 对象和 Blob 对象），其可以存储不少于 250M 的数据