本文是关于客户端存储(client-side storage)的。这是一个通用术语，包含几个独立但相关的 API： Web Storage、Web SQL Database、Indexed Database 和 File Access。每种技术都提供了在用户硬盘上 —— 而非通常存储数据的服务器 —— 存储数据的独特方式。这么做主要基于以下两点理由：(a)使 web app 离线可用; (b)改善性能。

这些 API 有着类似的作用范围和规则。我们先了解他们的共同之处吧。

共同特点基于客户端的存储

实际上，“客户端时间存储”的意思是，数据传给了浏览器的存储 API，它将数据存在本地设备中的一块区域，该区域同样也是它存储其他用户特定信息如个人偏好、缓存的地方。除了存储数据，这些 API 可以用来检索数据，且在某些情况下还能执行搜索和批处理操作。

置于沙盒中的

所有这四个存储 API 都将数据绑到一个单独的“源”(origin)上。例如，若 http://abc.example.com保存了一些数据，那以后浏览器就只会允许 http://abc.example.com获取这些数据。当我们谈论“源”(origin)的时候，这意味着域(domain)必须完全相同，所以 http://example.com和 http://def.example.com都不行。端口(port)也必须匹配，因此 http://abc.example.com:123也是不能访问到 http://abc.example.com(端口默认为80)存储的数据。同样，协议也必须一样(像http vs https 等等)。

空间限制（Quotas）

你能想象，如果任何网站都被允许往毫不知情的硬盘里填充以千兆字节计的数据，该有多混乱。因此，浏览器对存储容量施加了限制。若你的应用试图超出限制，浏览器通常会显示一个对话框，让用户确认增加。您可能以为浏览器对单个源(origin)可使用的所有存储都加以同一单独的限制，但多数存储机制都是单独加以限制的。若 Quota API被采纳，这种情况可能会改变。但就现在来说，把浏览器当作一个二维矩阵，其维度分别是“源”(origin)和“存储”(storage)。例如， “http://abc.example.com” 可能会允许最多存 5MB 的 Web Storage， 25MB 的 Web SQL 数据库，但因用户拒绝访问被禁止使用 Indexed DataBase。 Quota API 将问题放到一起来看，让您查询还有多少可用空间，有多少空间正在使用。

有些情况下，用户也能先看到有多少存储将被使用，例如，当用户在 Chrome 应用商店中安装一个应用时，他们将被提示预先接受其权限，其中包括存储限制。(而该应用的)manifest 中的可能有个值是 “unlimited_storage” (无限制存储)。

数据库处理（Transactions)

两个 “数据库” 的存储格式支持数据处理。目的和通常的关系型数据库使用数据处理是一样的：保证数据库完整。数据库处理(Transactions)防止 “竞争条件”(race conditions) —— 这种情况是：当两个操作序列在同一时间被应用到数据库中， 导致操作结果都无法被预测，而数据库也处于可疑的准确性(dubious accuracy)状态。

同步和异步模式（Synchronous and Asynchronous Modes）

多数存储格式都支持同步和异步模式。同步模式是阻塞的，意味着下一行 js 代码执行之前，存储操作会被完整执行。异步模式会使得后面的 js 代码在数据库操作完成之前执行。存储操作会背景环境中执行，当操作完成的时候，应用会以回调函数被调用这种形式接收通知，这个函数须在调用的时候被指定。

应当尽量避免使用同步模式，它虽然看起来比较简单，但操作完成时它会阻塞页面渲染，在某些情况下甚至会冻结整个浏览器。你可能注意到网站乃至是应用出现这种情况，点击一个按钮，结果所有东西都用不了，当你还在想是不是崩溃了?结果一切又突然恢复正常了。

某些 API 没有异步模式，如“localStorage”， 使用这些API时，应当仔细做好性能监测，并随时准备切换到一个异步API，如果它造成了问题。

API

Web Storage是一个叫做 localStorage 的持久对象。可以使用 localStorage.foo = "bar" 保存值，之后可以使用 localStorage.foo 获取到 —— 甚至是浏览器关闭之后重新打开。还可以使用一个叫做 sessionStorage 的对象，工作方式一样，只是当窗口关闭之后会被清除掉。

Web Storage 是 NoSQL 键值对储存(NoSQL key-value store)的一种.

Web Storage

数年以来，被所有现代浏览器支持， iOS 和 Android 系统下也支持(IE 从 IE8 开始支持 )。

简单的API签名。

同步 API，调用简单。

语义事件可保持其他标签和窗口同步。

Web Storage

使用同步 API(这是得到最广泛支持的模式)存储大量的或者复杂的数据时性能差。

缺少索引导致检索大量的或复杂的数据时性能差。(搜索操作需要手动遍历所有项。)

存储或读取大量的或复杂的数据结构时性能差，因为需要手动序序列化成字符串或将字符串反序列化。主要的浏览器实现只支持字符串(尽管规范没这么说的)。

需要保证数据的持续性和完整性，因为数据是有效非结构化(effectively unstructured)的。

Web SQL Database

Web SQL Database是一个结构化的数据库，具备典型 SQL驱动的关系数据库(SQL-powered relational database)的所有功能和复杂度。Indexed Database 在两者之间。Web SQL Database有自由形式的密钥值对，有点像 Web Storage，但也有能力从这些值来索引字段，所以搜索速度要快得多。

Web SQL Database

被主要的移动浏览器(Android Browser, Mobile Safari, Opera Mobile)以及一些 PC 浏览器(Chrome, Safari, Opera) 支持。

作为异步 API， 总体而言性能很好。数据库交互不会锁定用户界面。(同步API也可用于 WebWorkers。)

良好的搜索性能，因为数据可以根据搜索键进行索引。

强大，因为它支持事务性数据库模型(transactional database model)。

刚性的数据结构更容易保持数据的完整性。

Web SQL Database

过时，不会被 IE 或 Firefox 支持，在某些阶段可能会被从其他浏览器淘汰。

学习曲线陡峭，要求掌握关系数据库和SQL的知识。

对象-关系阻抗失配(object-relational impedance mismatch).

降低敏捷性，因为数据库模式必须预先定义，与表中的所有记录必须匹配相同的结构。

Indexed Database (IndexedDB)

到目前为止，我们已经看到，Web Storage 和 Web SQL Database 都有各种的优势和弱点。 Indexed Database产生于这两个早期 API 的经验，可以看作是一种结合两者优点而不招致其劣势得到尝试。

Indexed Database 是一个 “对象存储” (object stores) 的集合，可以直接把对象放进去。这个存储有点像 SQL 表，但在这种情况下，对象的结构没有约束，所以不需要预先定义什么。所以这和 Web Storage 有点像，拥有多个数据库、每个数据库又有多个存储(store)的特点。但不像 Web Storage那样， 还拥有重要的性能优势： 异步接口，可以在存储上创建索引，以提高搜索速度。

IndexedDB

作为异步API总体表现良好。数据库交互不会锁定用户界面。(同步 API 也可用于 WebWorkers。)

良好的搜索性能，因为数据可以根据搜索键进行索引。

支持版本控制。

强大，因为它支持事务性数据库模型(transactional database model)。

因为数据模型简单，学习曲线也相当简单。

良好的浏览器支持: Chrome, Firefox, mobile FF, IE10.

IndexedDB

非常复杂的API，导致大量的嵌套回调。

FileSystem

上面的 API 都是适用于文本和结构化数据，但涉及到大文件和二进制内容时，我们需要一些其他的东西。幸运的是，我们现在有了文件系统 API 标准(FileSystem API standard)。它给每个域一个完整的层次化的文件系统，至少在 Chrome 下面，这些都是用户的硬盘上的真正的文件。就单个文件的读写而言， API 建立在现有的 File API之上。

FileSystem

可以存储大量的内容和二进制文件，很适合图像，音频，视频，PDF，等。

作为异步 API， 性能良好。

FileSystem API

很早的标准，只有 Chrome 和 Opera 支持。

没有事务(transaction)支持。

没有内建的搜索/索引支持。

以上便是这些API的共同之处。