sessionStorage、IndexedDB 与 API 选择

sessionStorage 提供与 localStorage 完全相同的方法，但其生命周期与标签页绑定。标签页或窗口关闭时，其中的数据会自动清除。

它还按标签页隔离，因此两个标签页不会共享 sessionStorage 数据。

对于多步骤向导，sessionStorage 非常适合用来在当前会话中跨重新加载保留进度，并在标签页关闭后将其丢弃。

用户可以在填写表单期间刷新页面而不会丢失已输入内容，但完成或离开后不会留下任何数据。

IndexedDB 是浏览器内置的异步事务型数据库。它可以存储远超 localStorage 5MB 上限的数据，并能处理结构化对象、数组，甚至二进制数据。

由于它是异步的，因此不会像 localStorage 那样阻塞主线程。

原始 IndexedDB 应用程序接口冗长且基于事件，因此 idb-keyval 之类的库会将其封装为简单的基于 Promise 的函数，例如 get、set 和 del。

这样既能获得类似 localStorage 的使用体验，又能享受 IndexedDB 的容量和异步特性。

由于 IndexedDB 可以存储 Blob 和 ArrayBuffer 值，因此非常适合缓存图像、音频、下载的文件或离线资源。

这些数据很快就会超过 localStorage 的容量限制，而且必须先转换为字符串，而 IndexedDB 无需这样处理。

Cache 应用程序接口通常与服务工作线程结合使用，可以按请求存储完整的 HTTP Response 对象。它专为离线优先地缓存网络响应而设计。

离线时可以使用它提供资源和应用程序接口响应，而无需访问网络。

localStorage 会一直持久保留，直到被清除；sessionStorage 只在标签页会话期间保留；IndexedDB 会一直持久保留；Cookie 则可以通过其属性配置过期时间。

让所需的生命周期与合适的存储方式相匹配，可以避免对数据何时消失产生意外。

localStorage 和 sessionStorage 只能存储大约 5MB，Cookie 每个约为 4KB，而 IndexedDB 可使用数百 MB 甚至更多，具体取决于设备和浏览器。

对于任何较大规模的数据，IndexedDB 是浏览器中唯一实用的选项。

localStorage、sessionStorage 和 Cookie 都是同步的，访问期间会阻塞主线程。IndexedDB 和缓存 API 则是异步的，并且基于 Promise。

异步访问即使在读取或写入较大量数据时，也能保持用户界面的响应性。

请使用 httpOnly Cookie 存储身份验证令牌，以便脚本无法读取它们；使用 localStorage 存储少量持久化偏好设置；使用 IndexedDB 存储大型文件和复杂的离线数据；使用 sessionStorage 存储标签页内的短期草稿。

请根据数据的敏感性、大小和生命周期选择合适的存储方式。

不存在唯一最佳的存储 API；每种方式都需要在容量、持久性、同步行为和安全性之间进行权衡。了解它们的差异后，您就能有意识地进行选择。

典型应用通常会使用多种方式：使用 Cookie 处理身份验证，使用 localStorage 存储偏好设置，使用 IndexedDB 存储离线资源。

测试您对存储方式选择的理解。

您比较了 sessionStorage、localStorage、IndexedDB、Cookie 和缓存 API 在持久性、容量、同步行为及安全性方面的差异。

您学会了根据使用场景进行选择：使用 Cookie 处理身份验证，使用 localStorage 存储少量偏好设置，使用 IndexedDB 存储大型或复杂数据，使用 sessionStorage 存储限定在标签页内的草稿。