在当今的 Web 开发领域，选择合适的浏览器数据存储方法对于构建高效、功能丰富的应用程序至关重要。随着 Web 应用的不断演进，从早期的静态 HTML 页面到如今复杂的单页应用和本地优先应用，数据存储需求也日益多样化。本文将深入探讨 LocalStorage、IndexedDB、Cookies、OPFS（Origin - Private File System）和 WASM - SQLite 这几种常见的浏览器数据存储技术，比较它们的特性、限制，并通过性能测试揭示其在实际应用中的表现。

一、现代浏览器中的存储 API 概述

（一）Cookies

1994 年由网景公司引入的 Cookies，主要用于存储小型键值数据，在会话管理、个性化和跟踪等方面发挥着重要作用。它不仅存储在客户端，还会随每个 HTTP 请求发送到服务器，因此其存储容量有限，通常每个 Cookie 不超过 4KB（RFC - 6265 规定）。虽然其存储的数据量小，但由于是 Web 的重要基础特性，在性能优化方面一直备受关注，如 Chromium 的共享内存版本控制和异步 CookieStore API。

（二）LocalStorage

作为 2009 年 WebStorage 规范的一部分提出的 LocalStorage，提供了简单的 API 来存储键值对，包括 setItem、getItem、removeItem 和 clear 等方法。它适用于存储少量需要跨会话持久化的数据，存储上限一般在 4MB 到 10MB 之间（不同浏览器有所差异），例如 Chrome/Chromium/Edge 为 5MB，Firefox 为 10MB，Safari 为 4 - 5MB。需要注意的是，其 API 是同步的，在执行操作时会阻塞 JavaScript 进程，可能影响 UI 渲染。此外，还有 SessionStorage，其与 LocalStorage 的关键区别在于数据的生命周期，SessionStorage 在浏览器标签或窗口关闭时会清除数据。

（三）IndexedDB

2015 年首次推出的 IndexedDB 是一种低级 API，用于存储大量结构化 JSON 数据。尽管 API 使用起来有一定难度，但它支持索引和异步操作。不过，其早期版本缺乏对复杂查询的支持，仅允许通过索引迭代，更像是其他库的基础层。2018 年的 2.0 版本引入了 getAll () 方法，大幅提升了批量获取 JSON 文档的性能，而正在开发的 3.0 版本将包含更多改进，如基于 Promise 的调用，使现代 JavaScript 特性（如 async/await）更易于使用。

（四）OPFS

相对较新的 OPFS 允许 Web 应用程序直接在浏览器**中存储大文件，专为数据密集型应用设计，用于在模拟文件系统中读写二进制数据。**它有两种使用模式：在主线程上异步操作，或在 WebWorker 中使用 createSyncAccessHandle () 方法进行更快的异步访问。由于只能处理二进制数据，OPFS 主要作为库开发者的基础文件系统，对于普通应用开发者来说，直接使用可能过于复杂，更适合存储图像等普通文件，而非高效存储和查询 JSON 数据。

（五）WASM - SQLite

WebAssembly（WASM）作为一种二进制格式，于 2017 年开始在主流浏览器中得到支持，允许在 Web 上执行高性能代码。许多人开始将编译后的 SQLite 作为浏览器内的数据库使用。SQLite 的编译字节码约为 938.9kB，在首次页面加载时需要用户下载并解析。WASM 无法直接访问浏览器中的持久存储 API，需要通过虚拟文件系统（VFS）适配器将数据从 WASM 传输到主线程，再存入浏览器 API。

（六）WebSQL（已弃用）

WebSQL 于 2009 年推出，基于 SQLite，允许浏览器使用 SQL 数据库进行客户端存储。然而，由于它未标准化，依赖特定版本的 SQLite，且未得到所有主流浏览器（如 Firefox）的支持，近年来已从浏览器中移除，因此在后续讨论中将忽略它。

二、特性比较

（一）存储复杂 JSON 文档

在 Web 应用中，存储复杂 JSON 文档较为常见。只有 IndexedDB 原生支持 JSON 对象，WASM - SQLite 从 3.38.0 版本（2022 - 02 - 22）开始可以在 text 列中存储 JSON，并支持深度查询和使用单个属性作为索引。其他 API 只能存储字符串或二进制数据，虽然可以使用 JSON.stringify () 将 JSON 对象转换为字符串，但这可能会在查询时增加复杂性，多次使用还可能导致性能问题。

（二）多标签支持

与 Electron 或 React - Native 应用不同，Web 应用用户可能在多个浏览器标签中同时打开和关闭应用。并非所有存储 API 都支持自动在标签间共享写入事件，只有 LocalStorage 通过 storage - event 提供了自动共享写入事件的功能，可用于观察变化。对于 IndexedDB 等不支持的 API，开发者可以使用 BroadcastChannel API 在标签间发送消息来通知变化，或者使用 SharedWorker 在单个工作线程中进行所有写入操作，其他标签订阅该工作线程的消息以获取变化。

（三）索引支持

数据库与普通文件存储的一个重要区别在于索引支持，只有 IndexedDB 和 WASM - SQLite 开箱即支持索引。理论上可以在 LocalStorage 或 OPFS 等存储之上构建索引，但通常不建议自行构建。在 IndexedDB 中，可以通过给定的索引范围获取一批文档，例如查找价格在 10 到 50 之间的所有产品。不过，IndexedDB 对布尔值索引有限制，只能索引字符串和数字，需要在存储数据时进行转换。

（四）WebWorker 支持

在处理大量数据操作时，可能需要将处理从 JavaScript 主线程转移到 WebWorker、SharedWorker 或 ServiceWorker 中，以确保应用保持响应性和快速性。在 RxDB 中，可以使用 WebWorker 或 SharedWorker 插件将存储操作移到工作线程中。最常见的方式是生成一个 WebWorker 并在其中执行大部分工作，通过 postMessage () 与主线程通信。但 LocalStorage 和 Cookies 由于设计和安全限制，无法在 WebWorker 或 SharedWorker 中使用，而 OPFS 的快速版本（使用 createSyncAccessHandle 方法）只能在 WebWorker 中使用。

（五）存储大小限制

Cookies 存储容量约为 4KB，由于每次 HTTP 请求都会发送存储的 Cookies，因此此限制合理。LocalStorage 的存储大小限制因浏览器而异，如 Chrome/Chromium/Edge 为 5MB，Firefox 为 10MB，Safari 为 4 - 5MB。IndexedDB 和 OPFS 的最大存储大小取决于浏览器实现，通常基于用户设备的可用磁盘空间，在 Chromium 浏览器中可使用高达 80% 的总磁盘空间。

三、性能比较

（一）初始化时间

在存储数据之前，许多 API 需要设置过程，如创建数据库、启动 WebAssembly 进程或下载额外资源。LocalStorage 和 Cookies 无需设置即可直接使用，IndexedDB 需要打开数据库和内部存储，WASM - SQLite 需要下载 WASM 文件并进行处理，OPFS 需要下载并启动工作文件以及初始化虚拟文件系统目录。测试结果显示，打开一个新的 IndexedDB 数据库并创建单个存储的耗时较长；将数据从主线程发送到 WebWorker OPFS 的延迟约为 4 毫秒；下载和解析 WASM - SQLite 并创建单个表大约需要半秒，使用 IndexedDB VFS 持久化存储数据会额外增加 31 毫秒，启用缓存并预先准备好表后重新加载页面速度会稍快（内存模式下为 420 毫秒）。

（二）小数据写入延迟

在处理许多相互独立的小数据变化时，写入延迟很重要，例如从 WebSocket 流式传输数据或持久化鼠标移动等随机事件。测试结果表明，LocalStorage 的写入延迟最低，每次写入仅需 0.017 毫秒；IndexedDB 写入速度比 LocalStorage 慢约 10 倍；将数据发送到 WASM - SQLite 进程并通过 IndexedDB 持久化写入速度较慢，每次写入超过 3 毫秒；OPFS 操作将 JSON 数据写入每个文件的一个文档大约需要 1.5 毫秒，将数据发送到 WebWorker 会因数据序列化和反序列化的开销而稍慢，如果将所有数据追加到单个文件而不是为每个文档创建一个文件，性能模式会显著改变，使用 createSyncAccessHandle () 方法的更快文件句柄每次写入仅需约 1 毫秒，但需要记住每个文档的存储位置。

（三）小数据读取延迟

存储一些文档后，测量按 id 读取单个文档所需的时间。结果显示，LocalStorage 读取速度极快，每次读取仅需 0.0052 毫秒，其他技术的读取速度与其写入延迟相似。

（四）大数据批量写入

一次性执行 200 个文档的批量写入操作时，将数据发送到 WebWorker 并通过更快的 OPFS API 运行速度约快两倍；WASM - SQLite 在批量操作上的性能优于其单个写入延迟，因为一次性发送所有数据到 WASM 比逐个文档发送更快。

（五）大数据批量读取

批量读取 100 个文档时，在 OPFS WebWorker 中读取速度比在主线程模式下快约两倍；WASM - SQLite 读取速度令人惊讶地快，进一步检查发现 WASM - SQLite 进程会在内存中缓存文档，这在写入后立即读取相同数据时提高了延迟，若在写入和读取之间重新加载浏览器标签，查找 100 个文档则需要约 35 毫秒。

（六）性能总结

LocalStorage 速度快，但存在阻塞主线程、仅支持键值对存储且无法高效进行基于索引的范围查询等缺点，因此不应在大数据批量操作中使用。OPFS 在 WebWorker 中使用 createSyncAccessHandle () 方法比在主线程中直接使用快得多。WASM - SQLite 虽然可以很快，但初始下载和启动二进制文件需要约半秒，对于频繁打开和关闭的 Web 应用可能是个问题。

四、实际应用场景分析

在实际的 Web 开发中，不同的数据存储方法适用于不同的场景，开发者需要根据具体需求做出选择。

（一）LocalStorage 适用场景

1.简单偏好设置
对于存储用户的简单偏好，如页面主题（亮色或暗色模式）、语言选择等，LocalStorage 是一个理想的选择。这些数据量小且不需要复杂的查询操作，LocalStorage 的简单键值对存储方式能够轻松应对。例如，一个新闻网站可以使用 LocalStorage 来记住用户偏好的阅读字体大小或显示模式，每次用户访问时自动应用其偏好设置，提升用户体验。
2.临时数据缓存
当需要在浏览器会话期间临时缓存一些数据，如 API 请求的结果（在有效期内），以减少重复请求，LocalStorage 可以发挥作用。比如一个天气应用，在用户首次查询某个城市天气后，将结果缓存一段时间（假设 15 分钟），在这段时间内如果用户再次查看该城市天气，直接从 LocalStorage 读取缓存数据，而无需再次向服务器发送请求，既提高了应用响应速度，又减轻了服务器负担。

（二）IndexedDB 适用场景

1.离线应用数据存储
对于构建离线应用，如离线文档编辑器或离线音乐播放器，IndexedDB 能够存储大量结构化数据，如文档内容、音乐播放列表等。即使在离线状态下，用户也可以对这些数据进行操作，并且在重新联网后同步数据到服务器。例如，一个离线笔记应用，用户可以在没有网络连接时撰写和编辑笔记，笔记数据存储在 IndexedDB 中，网络恢复后将更新同步到云端服务器，确保数据不丢失且用户体验不受离线影响。
2.复杂数据管理与查询
当应用需要处理复杂的结构化数据，并进行频繁的查询和更新操作时，IndexedDB 的优势就凸显出来了。比如一个电商应用，需要存储商品信息（包括名称、价格、描述、库存等多个字段），并根据用户搜索、筛选条件（如价格范围、关键词等）快速查询和展示相关商品。IndexedDB 可以创建索引来优化这些查询操作，提高数据检索效率，确保应用的流畅运行。

（三）Cookies 适用场景

1.用户身份验证与会话管理
Cookies 在实现用户身份验证和会话管理方面有着广泛应用。服务器可以在用户登录成功后，通过设置 Cookie 来标识用户的登录状态，包含用户 ID 等关键信息。在后续用户的每个请求中，浏览器自动发送 Cookie，服务器据此验证用户身份，确定用户是否已登录以及其权限等。例如，一个在线银行系统，用户登录后，服务器设置包含用户账号信息的 Cookie，在用户进行转账、查询余额等操作时，服务器通过验证 Cookie 确保操作的安全性和合法性。
2.跟踪用户行为（需谨慎使用）
在一定程度上，Cookies 可以用于跟踪用户在网站上的行为，如记录用户浏览过的页面、点击过的链接等，以便为用户提供个性化推荐或分析用户行为模式。然而，这种跟踪行为需要谨慎处理，遵循相关隐私法规，确保用户知情权和选择权。例如，一个电商网站可能会使用 Cookies 来跟踪用户浏览过的商品类别，然后在首页或推荐页面展示相关商品的推荐信息，但必须明确告知用户并获得用户同意。

（四）OPFS 适用场景

1.大文件存储与处理
当 Web 应用需要处理大文件，如用户上传的图片、视频或大型文档时，OPFS 提供了合适的解决方案。它允许直接在浏览器中模拟文件系统来存储这些二进制文件，并且在 WebWorker 中使用时能够提供较好的性能。例如，一个在线图片编辑应用，用户上传高清图片进行编辑，图片数据可以存储在 OPFS 中，编辑过程中快速读取和写入文件，提高编辑操作的效率。
2.需要文件系统抽象的应用
对于一些需要类似本地文件系统抽象的应用，如在线代码编辑器（需要处理文件的保存、读取、目录结构等），OPFS 可以提供基础的文件系统功能支持。开发者可以基于 OPFS 构建更高级的文件操作逻辑，满足应用的特定需求。

（五）WASM - SQLite 适用场景

1.对 SQL 功能有需求的应用
如果 Web 应用需要强大的 SQL 功能，如复杂的多表关联查询、事务处理等，WASM - SQLite 是一个不错的选择。例如，一个企业级的 Web 应用，需要管理员工信息、项目信息、考勤数据等多个相关联的数据集，通过 SQL 的强大功能可以方便地进行数据的整合、分析和报表生成，WASM - SQLite 能够在浏览器端提供类似传统 SQL 数据库的功能支持。
2.性能要求较高的结构化数据存储（在特定情况下）
尽管 WASM - SQLite 初始化有一定延迟，但在处理大量结构化数据的存储和查询时，如果应用能够接受初始的启动开销，并且在后续操作中能够充分利用其性能优势，它可以提供高效的数据管理。比如一个数据分析 Web 应用，需要对大量历史数据进行存储和深度分析，WASM - SQLite 可以在内存中缓存数据，对于频繁的数据分析查询操作提供较好的性能表现。

五、总结与建议

在选择浏览器数据存储方法时，开发者需要综合考虑多个因素，包括数据类型、操作频率、存储容量需求、多标签支持、性能要求以及应用的特定场景等。
LocalStorage 简单易用，适用于少量简单数据的持久化存储，但在处理大量数据和复杂查询时存在局限性。IndexedDB 功能强大，适合处理大量结构化数据和复杂查询，但 API 复杂，学习成本较高。Cookies 主要用于会话管理和与服务器的交互，但存储容量小且安全性需谨慎处理。OPFS 专为大文件存储和文件系统操作设计，在特定文件处理场景下表现出色，但对于普通 JSON 数据存储和查询不太方便。WASM - SQLite 提供了强大的 SQL 功能，但初始化延迟和对 WebAssembly 的支持要求需要开发者权衡。
在实际应用中，开发者可以根据具体需求灵活组合使用这些存储方法，以达到最佳的性能和功能平衡。例如，在一个大型 Web 应用中，可以使用 LocalStorage 存储用户的基本设置和临时状态，IndexedDB 用于核心数据的存储和查询，Cookies 进行用户身份验证和会话管理，OPFS 处理大文件上传和存储，WASM - SQLite 在需要高级 SQL 功能的特定模块中使用。同时，关注浏览器技术的发展动态，及时利用新的特性和改进，为用户提供更好的体验。