Web应用开发中的本地存储限额localStroage Quota

近几年互联网络的发展似乎进入一个瓶颈期。不独一时一地，全球趋势大致如此，大概处于传统互联网络已经日至成熟，而创新技术在萌芽期尚未获得突破之际。所以传统互联网络技术只好在细节上打磨、内卷（involution）和进化（evolution），以此来消磨革命性（revolution）和创新性（innovation）技术来临前的时光。Web应用（网页应用）的开发者中新推进的本地化静态存储locaStorage就是这方面的一个代表。

作为矢志不渝的目标之一，Web应用要在性能和体验上追赶并且超越本地应用，除了客户端机器本身性能和网络带宽的飞速提升，Web应用本身对数据的处理也是重要的革新和优化方向之一。将Web应用中的常用数据在客户端本地进行持久化静态存储是个不错的主意，目前多数浏览器已经支持，而且一经推出即获得好评和广泛应用部署。比如在我们最近的老项目有福新闻（UfqiNews， https://ufqi.com/news ）和新项目有福金融（UfqiFina， https://ufqi.com/finance ）中，都有用到网页对象 window.localStorage对象对用户常用的交互数据进行本地化储存。

处于谨慎安全与性能考虑，浏览器的本地存储localStore对象给与每个域名的空间是有限的，这个限制是理性的和平衡的。有了这个限制，在调用localStorage 进行本地存储操作时，就可能会触及限额超额的问题。目前多数浏览器默认的window.localStorage的限额为每个域名5MB的空间. 基本上节省点用，一些基本需求还是可以得到满足的。

这个节省点用，是个模糊的描述。最近我们在Web开发中就遇到了localStorage报错说超额失败了。这个错误信息大致描述为：

DOMException: Failed to execute ‘setItem’ on ‘Storage’: Setting the value of ‘A_USER_KET_NAME’ exceeded the quota.

至少有两个公开的Web应用中存在很容易触发类似问题进而影响正常功能使用的现象, 比如第三方共享/分享插件 ShareThis 和博客程序 WordPress 。引起window.localStorage的问题可能很多，ShareThis 和 WordPress报错也不一定是他们本身存储了太多的东西，但目前发现，他们由于localStorage问题影响了正常功能使用。

ShareThis 的Web页面的JavaScript程序对访问过的每一个页面无差别地将其写入本地存储localStorage，写入时Key为 st_shares_URL_WITH_PARAMETERS , 这很恐怖的导致 localStorage 存储尺寸飞速上升，如果访问页面地址很长，而用户又在一个domain站点里访问了很多页面，我们观测到当我们在 UfqiNews 访问2000+页面时，localStorage 存储ShareThis的数据已经开始报错超额了！😢

WordPress 的新版本在启用编辑器时，会调用localStoage，当操作localStorage读写失败时，编辑器就无法使用了。😰

上述读写本地存储localStorage问题表现在：
1) 同一个页面功能不该创建过多的Keys，比如ShareThis, 应该将所需本地化的数据统一放入一个 ShareThis_LocalStoage 主键Key下面，然后再是各个key/value 对，更加明确；
2）既然 localStorage有限额quota，那么在设计数据结构时和流转机制时，就应该以某种先进后出或者先进先出的形式，有定期更新和删除操作，不然再大的空间也有用完耗尽的一天；
3）既然 localStorage有限额quota ，那么在设计读写操作程序时，就应该有错误处理机制，当遇到无法返回预期数据处理结果时，应该平滑地进行下面的操作，或读取远程服务器数据或操作磁盘文件系统，而不应该让程序因此而卡壳掉。

我们在有福新闻UfqiNews和有福金融的开发中就遇到类似需求。当我们需要存储用户个性化的一些动态信息时，比如用户最近阅读的主题词或者用户查询的基金代码等。在没有window.localStorage对象之前，只能在服务器端存储，在服务器端上维持个庞大的用户浏览历史记录表，而且需要实时高并发的写入更新。这存储还可以，高并发的写入更新实在勉为其难。window.localStorage生逢其时，可以很好的满足这个需求，我们可以将用户的浏览历史数据，写入本地localStorage, 既是个性化、分布式的，也避免了实时高并发地写入更新服务器数据。

有鉴于在本地存储中 ShareThis 和 WordPress上述问题的经验教训，我们在设计本地存储时，
1)遵循了一个功能点，设计为一个主键Key的方式，然后将相应的数据放入这个主键Key下面，以JSON等方式进行读写。
2)同时，考虑到本地读写的便捷性，我们还对历史数据进行排序和统计，让更高频地使用的主题词或条目排列在最前面，方便用户更快捷地命中信息。
3)基于这些统计数据，我们对所要存储的数据有了把握，可以控制要存储的数据条目数和所占用空间的尺寸。定期或者按需清除不需要的数据，从而节省有限的 window.localSroage空间，以图长久。
4)考虑到在服务器端无法感知的本地存储限额异常错误的发生，在运行时，如果读写本地存储异常时则跳过功能点继续其他页面流程，而不是卡壳程序。

在内卷（involution）和进化（evolution）过程中，没有革命性（revolution）和创新性（innovation），我们能依靠的只有在细节上更精准地把握，才有可能产生新的突破（disruption），从而完成由量变到质变的飞跃（leap）。
JavaScript担当起Web应用开发的主角，还有很长的路要走，但前途是光明的，恰如数年前我们所预见的那样：JavaScript或成主导的编程语言（ https://dl.ccf.org.cn/article/articleDetail.html?id=3738875941521408 ）。如果不去体验几乎难以想象，上面的fig.2.基金行情K线图是完全基于JavaScript的 HighChartStock 所绘制出来的。

有福新闻 UfqiNews

这里呈现热点全局, 尺寸间一览所有令人关注的疑点焦点;
这里表达条分缕析, 视野内一睹各个脉络清晰的故事主线.
有福新闻UfqiNews 带来全新的资讯阅览体验, 不信息过载, 亦不信息茧房.
在寻求最大社会共识和满足千人千面之间谋取平衡,
在满足广泛涉猎与追求术业专攻之间谋取平衡.
媒介插上人工智能的翅膀将如虎添翼, 与资讯比翼双飞.
新闻爱好者的良心之选, 匠心之作.

UfqiNews presents the hot spots globally, with all interesting points at a glance.
Information is organized here and there is a clear storyline within every single detail.
UfqiNews brings a brand new reading experience, no information overload and no information Cocoons,
In seeking a balance of the maximum social consensus and meeting thousands of people for each interest,
In achieving a balance between satisfying a wide range of hunting and pursuing specialization in the industry.
That media is being born with wings of the artificial intelligence will be even more powerful and the information will fly swifter than ever.
Better choices of newsreaders and the art of work from them.