1、Web SQL Database
虽然还有浏览器支持，是唯一的关系数据库结构的存储，但W3C以及停止对其的维护和发展，所以这里我们也不再对其进行介绍
2、localStorage(有用)
先介绍最简单的存储方式LocalStorage，代码如下，几乎不用介绍就是Key-Value的简单键值对存储结构，Web Storage除了localStorage的持久性存储外，还有针对本次回话的sessionStorage方式，一般情况下localStorage较为常用
localStorage和cookies相比，在浏览器中存储的容量更大。另外最大的特点是不会附带在http请求中传给后台，不会像cookies一样导致http头部变大影响传输性能。基于这个原因，localStorage适合缓存一些常用的数据，无需平凡的像后台请求数据。
假设业务场景中有某段数据是被多个地方用到的，最直观的做法是：
var data = localStorage.getItem('cacheKey');
if (!data) { // 如果data为空，发出请求
$.ajax({
url: 'xxxx',
success: function(response) {
if(response.code === 1) { // success!
loccalStorage.setItem('cacheKey', response.data);
}
// 其他业务处理。。。
}
})
}
如果接口设计是统一的，可以统一封装自己的ajax方法，拦截请求
function myAjax() {
var arg = arguments[0];
var realSuccess = arg.success;
var realBeforeSend = arg.beforeSend;
arg.success = function(response) {
if(response.code === 1) {
localStorage.setItem(cacheKey /*需要根据请求参数生成不一样的key*/ , response.data);
}
realSuccess && realSuccess.apply(null, arguments);
}
$.ajax(arg);
}
如上面代码，同理可以增加beforeSend拦截请求判断是否在缓存中读取。这样业务逻辑就更少的受到影响
3、Cookie常见的(有用)
4、IndexedDB(有用)
本地数据库
5、FileSystem API(有用)
突破沙箱访问我们本地的文件系统
6、Application Cache
1.更新机制：一旦你采用了manifest之后，你将不能清空这些缓存，只能更新缓存，或者得用户自己去清空这些缓存。这里一旦更新到错误的页面，将被缓存起来，而无法有机会访问到正确的页面，那么就只能杯具了，所以保证更新的页面资源的正确性显得尤为重要。另外电信之类的运营商很喜欢在一些流量大的网站进行劫持广告，这样的话，很可能在更新过程将这些广告给缓存起来了，那就杯具了。
2.manifest本身的编写要求比较严格，要注意换行跟路径文件名之类的问题。不然缓存将无效。
3.如果更新的资源中有一个资源更新失败了，将导致全部更新失败，将用回上一版本的缓存。
4.二次更新的问题，即在更新新版本过程中，用户需要第一次时访问的还是旧的资源，需要第二次进去才是新的资源。如果此时后台接口发生变化，访问第一次时的旧数据很可能将出现兼容问题。
5.限制大小问题，一般是最多缓存5mb，不过一般是够用的。
6.回滚问题，这个可以参考之前的一篇《慎用manifest》的文章，大体是从无到有，又想回滚到无的情形。总体来说，appcache是把双刃剑，用的好的话，那将获益良多，用不好将是用户的一个灾难。
