本版本亮点是加入本地储存的支持与版本控制。
根据我们正常的思路，上线前我们会把这个页面的所有JS文件打包成一个，或尽可能少的JS文件，其目的是减少请求数。然后，模块化带来的一个直接结果是把一个框架打散成N多JS文件，真是反其道而行。但是一个网站是由许多页面组成，每个页面其实都是引用N个相同的JS文件（包括基础库，工具库与通用组件库），与针对这个页面的专用JS文件。因此想搞鼓出最优的打包方案是很难的，打包后我们图的是利用浏览器的静态缓存减少对服务器的压力！不过，请神容易送神难，静态缓存后，我们想刷掉这缓存比较麻烦，不能要求用户按F5或Ctrl+F5来清吧！涉及CDN就更麻烦了。而且合并JS后，意味着服务器的内存保存着对应的合并副本，文件越多，组合越多！因此我结合本地储存，得出的结论是不对JS文件进行缓存！下面是我的详细思路：
页面引入mass Framework的种子模块mass.js，然后我们开始写业务代码，用到什么功能就用$.require("xxx,yyy",fn)引入对应的模块就行了。
在mass Framework中，模块即文件，于是加载文件去。在加载之前，我们有两个判定，判定此模块是否已经加载过，即它是否存在于内存！没有再判定它是否保存过，即它是否序列化到用户机器上，针对不同的浏览器，我们分别使用userData与localStorage。如果不支持这两种最流行的本地储存就算了，我也懒得兼容比IE5.5更2B的浏览器！如果在内存中，我们可以直接用，如果在本地储存中，我们把这些字符串还原为函数也可以用！如果两者都不，就远程加载。因此上面的require操作，我们是加载了两个JS文件，然后把它们的模块工厂，JS文件路径，依赖列表等都立即保存到本地储存去！之后所有操作都以原来的一样。
本地储存应用后的区别在于，以后无论是什么刷新页面，或跳转到本站的其他页面，只要你用到这个模块，它都不发出请求了！如果是静态缓存还会发出请求的。带来的好处是，整个网站，除了种子模块之外，其他JS文件都是请求一次！由于模块系统的存在，让按需加载成为现实，因此用户实际请求数可能更少！
想应用本地储存功能，不需要调用函数，也不要传参，只要在引用种子模块的script标签添加一个storage属性就行，值为1或true。
<script src="/scripts/mass.js" storage="1"></script> |
好了，当我们对一个JS模块进行了修改，那怎么办呢？框架提供了两种方式把它从本地储存中清掉。一种是服务器端的，写入一个cookie，键名为erase（这个也可以配置）,值为一个序列化后的对象。这个对象是个样子的：
{ } |
键名为模块的URL，值为它的版本号。我是使用时间戮做版本号的。只有这个JS文件发生变化，我才把它放进此对象，然后"erase="+ JSON.stringify(object)发到前端去。
在前端，框架会读取cookie，发现有erase这个键名，就把它的值取出来，然后还原为一个对象，然后遍历它的键值对，比较本地储存中那个模块的版本号，如果它比现在的旧，就把它清掉！
下面是框架的具体执行代码：
var rerase = new RegExp('(?:^| )' + $.config.erase + '(?:(?:=([^;]*))|;|$)') var match = String(DOC.cookie).match( rerase ); //读取从后端过来的cookie指令，转换成一个对象，键名为模块的URL，值为版本号（这是一个时间戮） if(match && match[1]){ try{ var obj = eval("0,"+match[1]); for(var i in obj){//$.erase会版本号比现在小的模块从本地储存中删掉 $.erase(i, obj[i]) } }catch(e){} } |
这就是通过后端的cookie指令清除指定模块！
我们也可以在前端自己调用$.erase(url, version)会删掉指定模块！
上面也提到过cookie指令的名字也可以配置的，也和storage一样，在引用种子模块的script标签添加一个erase属性，值为你想要的名字就行了！
本次版本的升级只添加了一个erase方法，所有的改进都在内部进行的！
历史回顾！不断完善，臻于完美！
/*v2 没有保留下来v1 没有保留下来*/ |
