如果您需要以有保证的持久性存储数据，那么您需要在后端使用某种类型的数据库。
如果您不需要持久性保证，那么有时将数据存储在客户端（在用户的浏览器中）是一个更可行的选择。其他时候，可能必须使用浏览器端存储。
点击标题是原文，它谈了：
- 当前选项 - 您现在可以在所有现代和大多数旧浏览器中使用的 API
- 未来选项 - 尚未完全支持浏览器的 API
- 过去的选项 - 您应该避免的已弃用 API
这是摘要：
当前选项
- 网络存储
Web Storage API允许您存储键/值对。
您可以将 localStorage 用于持久数据，将 sessionStorage 用于临时会话数据。
浏览器将每个域限制为 5 兆字节，并且读/写操作是同步的，因此它们可以延迟其他 JavaScript 进程。
Web 存储也是纯字符串的，因此您可能必须对数据进行序列化/反序列化。
此外，保存大型数据集会影响页面性能（因为操作是同步的）。
- 索引数据库
IndexedDB API用于存储大量结构化数据。
数据存储限制非常大（如果存在的话），但各种浏览器处理限制和数据驱逐的方式不同。
IndexedDB 为您提供了一个类似 NoSQL 的键/值数据库，您的值可以是复杂的结构化对象。
每个 IndexedDB 对一个源来说都是唯一的，因此任何其他源都不能访问它。
API 使用数据库索引来实现对数据的快速搜索（因此称为Indexed DB）。
API 大部分是异步的（你必须传递回调函数），它建立在事务数据库模型上。事务是原子的，但IndexedDB 不提供事务隔离保证（针对多个选项卡中的并发事务）。
IndexedDB 的主要缺点是 API 很差。
但是，您可以使用 idb 之类的包装器使其可用（这是大多数开发人员所做的）。
- Cookie
严格来说，cookie 不是客户端存储选项，因为浏览器和后端服务器都可以修改 cookie。
但是，cookie 是最流行的浏览器端存储选项之一，它们对于任何维护服务器/浏览器状态的系统（例如登录）都是必不可少的。
一个域可以存储不超过 20 个命名 cookie，每个最大字符串为 4 KB。
这是一个 80 KB 的限制性限制，但这是因为每个 HTTP 请求和响应都会发送 cookie 数据。
但是，cookie 的一些缺点（除了有限的存储空间）包括
- 需要字符串序列化和反序列化
- 浏览器和插件可以阻止 cookie
- 法律要求（您可能需要选择加入或警告）
- 缓存 API
缓存 API 存储 HTTP 请求和响应对象。
它主要用于 PWA 缓存网络响应，以便应用可以在离线时提供缓存的响应。
Cache API 对于存储其他类型的数据并不实用。
基于 Chrome 的浏览器通常允许每个域 100 兆字节，但 Safari 将其限制为 50 兆字节并在 14 天后驱逐缓存。
过去的选择
- WebSQL
WebSQL 为浏览器带来了类似 SQL 的数据库存储，任何了解 SQL 的人都可以使用它。
然而，Chrome 和 Safari 提供了各种不一致的 WebSQL 实现，而 Mozilla 和微软反对它，支持 IndexedDB。
API 在 2010 年被弃用。
- 应用缓存
AppCache 是 Cache API 的前身。
它试图在纯文本清单文件中指定缓存行为，但围绕 AppCache 存在许多问题和陷阱，可能会破坏您的网站。