无论是本地设备存储空间还是基于云的服务器存储，选择合适的存储机制都至关重要。一个好的存储引擎可确保可靠地保存信息、减少带宽并提高响应速度。正确的存储缓存策略是实现离线移动网络体验的核心要素。
本文简要介绍了评估 Storage API 和服务的基础知识，随后提供了对比表和一些一般性指导。在不久的将来，我们计划添加一些资源，以便您更深入地了解所选存储主题。
存储分类
首先，我们来了解一下可以从哪些维度分析 Web 应用的数据存储区。稍后，我们将使用此框架来枚举和评估 Web 开发者可用的众多存储选项。
数据模型
存储数据单元的模型决定了数据在内部的组织方式，这会影响存储和检索请求的易用性、费用和性能。
结构化：存储在具有预定义字段的表中的数据（如基于 SQL 的数据库管理系统中的典型数据）非常适合灵活和动态的查询，其中可能无法事先知道所有查询类型。浏览器中结构化数据存储区的一个典型示例是 IndexedDB。
键/值：键/值数据存储区和相关的 NoSQL 数据库能够存储和检索由唯一键编入索引的非结构化数据。键值对数据存储区类似于哈希表，因为它们允许在恒定时间内访问已编入索引的不透明数据。键值对数据存储区的典型示例包括浏览器中的 Cache API 和服务器上的 Apache Cassandra。
字节流：这种简单模型将数据存储为可变长度的不透明字节字符串，将任何形式的内部组织留给应用层。此模型特别适用于文件系统和其他分层组织的数据 blob。字节流数据存储区的典型示例包括文件系统和云端存储空间服务。
持久性
Web 应用的存储方法可以根据数据持久化的范围进行分析。
会话持久性：此类数据仅在单个 Web 会话或浏览器标签页保持活跃状态期间保留。具有会话持久性的存储机制的一个示例是 Session Storage API。
设备持久性：此类数据会在特定设备上的不同会话和浏览器标签页/窗口之间保留。Cache API 就是一种具有设备持久性的存储机制。
全局持久性：此类数据会跨会话和设备保留。因此，它是最可靠的数据持久化形式。Google Cloud Storage 就是一种具有全局持久性的存储机制。
浏览器支持
开发者应选择最适合其问题领域的 API；不过，他们还应考虑到，标准化且完善的 API 优于自定义或专有接口，因为它们往往寿命更长，支持更广泛。他们还可能享有更广泛的知识库和更丰富的开发者生态系统。
交易
通常，一组相关的存储操作必须以原子方式成功或失败。数据库管理系统传统上使用事务模型支持此功能，其中相关更新可以分组为任意单元。虽然并非总是必要，但在某些问题领域，这是一项方便且有时必不可少的功能。
同步/异步
某些 Storage API 是同步的，这意味着存储或检索请求会阻塞当前活跃的线程，直到请求完成。这在网络浏览器中尤其繁重，因为存储请求会与界面共享主线程。出于效率和性能方面的考虑，应首选异步 Storage API。
在 Chrome 开发者工具中调试存储
请参阅以下文档，详细了解如何使用 Chrome 开发者工具检查和调试您选择的 Web Storage API。此处未提及的 API 要么在开发者工具中不受支持，要么不适用。
如果您使用的是多个 Storage API，请查看 DevTools 的清除存储空间功能。借助此功能，您只需点击一个按钮即可清除多个商店。如需了解详情，请参阅清除 Service Worker、存储空间、数据库和缓存。
下一步做什么…
现在，我们已经回顾了思考存储机制的一些相关方法，并比较了当今最流行的 API 和服务，我们很快就会添加更多内容，以更深入地探讨一个或多个感兴趣的主题：