虽然有很多关于 html5 的好东西，但我不明白的是 redondant 存储机制，首先是 localstorage 和 sessionStorage，它们是键值存储，一个是针对应用程序的一个实例（“一个选项卡” )，另一个适用于该应用程序的所有实例，因此它们可以共享数据。当您关闭浏览器并且大小有限（通常为 5MB）时，两者都会保存，这很好，如果我们停在那里，一切都会很好。
但是还有“Web SQL 数据库”，它具有与本地存储相同的安全系统、相同的大小限制、除了它像 / 是 sqlite 一样工作之外的所有内容、表和 sql 语法等等。
不幸的是，他们根本不处理相同的数据！这不是访问数据的两种方式，这实际上是每个 html 5 应用程序的两个存储（默认情况下不是创建的，是的，但你仍然明白我的观点）。
我想知道的是，这两种机制是否有理由同时存在？或者他们只是看一下 sql 和 nosql 的运动来选择最好的然后去“搞砸了，让我们两者都加！” ? 为什么不将本地/会话存储实现为 web sql db 中的表？
我的看法是，localstorage 是对最初应该完成的 cookie 方式的正确重写。它有一个非常简单的 api 和低采用障碍。
Web SQL 的任务相当繁重，如果只保存一个简单的值会很痛苦，因此它们有非常不同的用例。localstorage 实际上是在 WebKit 中使用 SQLite 实现的，但不是通过 WebSQL 公开的。
会话存储无法在数据库内轻松实现，因为它有效地在全局范围内，并且您不希望数据对其他选项卡可见。因为它是临时数据，所以您通常不希望存储大量数据，因此不需要事务和查询。
我问自己同样的问题，下面是来自 Chromium wiki 的答案：
问：为什么要通过 LocalStorage？
答：LocalStorage 本质上是活泼或并行灾难，这取决于您是否愿意实现规范中描述的“存储互斥锁”。Chromium 决定不实施它。WebKit 本身是单线程/进程（即没有并行期）
来源： http: //www.chromium.org/developers/design-documents/indexeddb
如果您想在本地复制数据库结构以供离线使用，Web SQL 会很有用。
但是 Web SQL 不会在 firefox 中实现： http ://us1.campaign-archive.com/?u=168bf22f976f5a68fe5770d19&id=6c2d73c957#standards
Mozilla、Microsoft 和 Oracle 正在研究“IndexedDB”替代方案：http ://www.w3.org/TR/IndexedDB/
Firefox 中正在进行的工作：https ://wiki.mozilla.org/Firefox/Projects/IndexedDB
存储演示：