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