这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
浏览器缓存
浏览器缓存机制其实有四个方面，分别是
- Memory Cache
- Service Worker Cache
- HTTP Cache
- Push Cache
我们可以看到，像这种没有size大小的描述就是从缓存中获取的
强缓存
强缓存是利用 http 头中的 Expires 和 Cache-Control 两个字段来控制的。当请求再次发出的时候，浏览器会根据这两个字段来判断目标资源是否命中强缓存，如果有则直接在缓存中获取资源，否则与服务器通信
命中的话返回的HTTP状态码也有所不同
- expires：时间戳
- Cache-Control ：时间长度 例如（ max-age=31536000）
max-age 机制下，资源的过期判定不再受服务器时间戳的限制。所以说，Cache-Control 的 max-age 配置项相对于 expires 的优先级更高。当 Cache-Control 与 expires 同时出现时，我们以 Cache-Control 为准。
Cache-Control 应用分析
s-maxage 优先级高于 max-age，两者同时出现时，优先考虑 s-maxage。如果 s-maxage 未过期，则向代理服务器请求其缓存内容。
s-maxage仅在代理服务器中生效，客户端中我们只考虑max-age。
public 与 private
如果我们为资源设置了 public，那么它既可以被浏览器缓存，也可以被代理服务器缓存；
如果我们设置了 private，则该资源只能被浏览器缓存。private 为默认值
no-store与no-cache
顾名思义，第一个向服务器确认资源是否过期，第二个所有缓存都不要
协商缓存
协商缓存依赖于服务端与浏览器之间的通信。
协商缓存机制下，浏览器需要向服务器去询问缓存的相关信息
如果服务端提示缓存资源未改动（Not Modified）,资源会被重定向到浏览器缓存，这种情况下网络请求对应的状态码是 304
Last-Modified 和 Etag
Last-Modified ：时间戳
如果启用了协商缓存，他会在首次请求时随着Response Headers返回
Etag 是由服务器为每个资源生成的唯一的标识字符串
主要解决请求速度过快， Last-Modified感知不到变换
Etag 在感知文件变化上比 Last-Modified 更加准确，优先级也更高。当 Etag 和 Last-Modified 同时存在时，以 Etag 为准。
缓存决策
MemoryCache
MemoryCache，是指存在内存中的缓存。从优先级上来说，它是浏览器最先尝试去命中的一种缓存。从效率上来说，它是响应速度最快的一种缓存。
Service Worker Cache
Service Worker 是一种独立于主线程之外的 Javascript 线程。它脱离于浏览器窗体，因此无法直接访问 DOM。
Push Cache
- Push Cache 是指 HTTP2 在 server push 阶段存在的缓存。
- Push Cache 是缓存的最后一道防线。浏览器只有在 Memory Cache、HTTP Cache 和 Service Worker Cache 均未命中的情况下才会去询问 Push Cache。
本地缓存
Cookie
Cookie 的本职工作并非本地存储，而是“维持状态”。
关键词
存储在浏览器的文本文件，附着在 HTTP 请求上，浏览器和服务器之间“飞来飞去”
缺点
- 体积太小，只有4KB
- 过量的Cookie会带来巨大的性能浪费
为什么？我们知道，Cookie 是紧跟域名的，在响应头里Set-Cookie 指定要存储的 Cookie 值。
例子
Set-Cookie: name=xxx; domain=xxx
同一个域名下的请求都会携带Cookie，如果Cookie过多，仅仅是请求一张图片或者CSS也要携带Cookie，那产生的开销是巨大的。随着前端的复杂度提高，为了维护状态，常常往cookie塞很多的数据，为了弥补 Cookie 的局限性，Web Storage 出现了。
Web Storage
借用mdn解释
Web Storage API 提供机制，使浏览器能以一种比使用 Cookie 更直观的方式存储键/值对。
Local Storage 与 Session Storage 的区别
- 前者持久化的本地存储，数据永远不会过期，只能手动删除，后者临时本地存储，随着会话结束而消失
- 两者都遵循同源策略，但后者如果不在同一个窗口打开，则无法共享数据
特性
- 容量大
- 仅在浏览器端，不会与服务端发生通信
API使用
直接看文档吧
developer.mozilla.org/zh-CN/docs/…
应用场景
Local Storage
- Base64 格式的图片字符串
- css、js等静态资源
Session Storage
- 上次访问的地址
- 生命周期和它同步的会话级别的信息
更大的存储,只能在Web Worker中使用---IndexedDB
IndexedDB 是一种底层 API，用于在客户端存储大量的结构化数据（也包括文件/二进制大型对象（blobs））。该 API 使用索引实现对数据的高性能搜索。虽然 Web Storage 在存储较少量的数据很有用，但对于存储更大量的结构化数据来说力不从心。而 IndexedDB 提供了这种场景的解决方案。
IndexedDB 特点
- 非关系型数据库
- 持久化存储
- 异步操作
- 支持事务
- 同源策略
- 存储容量大
那我们为什么要用IndexedDB而不是localStorage呢？
- indexedDB 原生支持 object、Date、undefined、NaN、Infinity、以及自引用 object 的读写。这是 localStorage 所不支持的，虽然可以借助
JSON.stringify()实现转换，但仍然难以完全支持上述的这些类型。 - indexedDB 的存储空间足够大，一般来说不少于 250M，大小一般是硬盘大小的 50%。而 localStorage 最大存储量一般不高于 5M。
- indexDB 原生基于异步方式实现，不必担心使用其在读写数据的过程中发生错误而阻塞应用程序的正常运行。
缺点
使用过程较为复杂，需要进一步操作和封装，平时业务的数据量可能不大，一般我们用不到indexedDB。
总结
本文主要学习缓存的一些心得和笔记，原来缓存也有那么多的知识，需要进一步研究🧐。
