LocalStorage是一个HTML5网络存储对象，用于在客户端（即本地用户计算机上）存储数据。存储在本地的数据没有过期日期，并且会一直保留到删除为止。（相比之下，会话存储是另一种HTML5网络存储API，它会在浏览器关闭时删除存储的数据。）本地存储是纯JavaScript。此外，虽然它仍会在用户设备上生成纯文本文档，但本地存储还允许存储多达5MB的数据（与4KBcookie相比）。这使得本地存储的许多有趣应用成为可能，例如管理内容以减少从服务器请求内容的需要，加快加载时间。只读的localStorage属性允许您访问一个Document源（origin）对象存储；存储的数据将保存在浏览器会话中。localStorage与sessionStorage类似，不同的是localStorage中存储的数据可以长期保留；而当页面会话结束时——即页面关闭时，sessionStorage中存储的数据将被清除。localStorage的主要特点是：在同源的所有标签页和窗口之间共享数据。数据不会过期。它会在浏览器重启甚至系统重启后持续存在。sessionStorage对象的使用频率远低于localStorage对象。属性和方法是一样的，但它有更多的限制：sessionStorage数据只存在于当前浏览器选项卡中。具有相同页面的另一个选项卡将具有不同的存储空间。但是，它在同一选项卡下的iframe之间共享（前提是它们来自同一来源）。数据会在页面刷新时持续存在，但不会在浏览器选项卡关闭/重新打开时持续存在。使用本地存储的示例：创建一个文本区域字段，只要它的值发生变化就可以“自动保存”。所以，如果用户不小心关闭了页面，再重新打开，会发现之前未完成的输入还在。像这样：
清除如果使用得当，本地存储可以成为一种强大的轻量级数据存储解决方案，但它并非没有问题。以下是使用本地存储可能不是一个好主意的几个原因，具体取决于存储的内容。为什么使用LocalStorage可能不是一个好主意本地存储本身并不比使用cookie更安全。了解这一点后，该对象可用于存储从安全角度来看无关紧要的数据。但是，这里有一些重新考虑使用本地存储的原因。1.如果站点容易受到XSS攻击，LocalStorage是不安全的也许使用本地存储的最大反对意见是与之相关的安全漏洞。本地存储具有许多与cookie相同的特征，包括相同的安全风险。其中之一是对跨站点脚本的敏感性，它会窃取cookie并让黑客伪装成具有站点登录会话的用户。在本地存储中存储密码等敏感内容实际上简化了黑客的过程，因为他们不需要将cookie加载到浏览器中。2.开发人员无法控制本地存储的数据有了本地存储，就没有服务器端存储——没有开发人员可以控制的数据库。由于一些原因，这可能会出现问题，其中之一是开发人员无法在存储后更新代码或信息。用户需要手动删除该文件，这需要先找到它。或者，他们需要擦除浏览器缓存，从而丢失所有存储的数据。3.用户清除缓存定期清除浏览器缓存有助于cookie更有效地发挥作用，这通常是人们在解决浏览器问题（例如页面无法正确加载）时采取的第一步。当使用本地存储来支持站点的功能时，这是一个问题。如果用户清除浏览器缓存，这些信息将永久丢失。这使得本地存储作为备用数据库更有用。LocalStorage的替代方案确实存在一些本地存储的替代方案，具体取决于信息是否敏感。不想使用本地存储的开发人员可以尝试以下方法：##对敏感信息使用服务器端会话当涉及到敏感信息时，将数据存储在服务器上有几个优点。首先，开发人员可以保证他们的安全并对单个会话有更多的控制（如果需要，他们可以立即终止）。其次，数据在架构中受到保护，暴露的机会更少。对于非敏感信息，选择IndexedDB对于专注于客户端会话的开发人员，IndexedDB使开发人员能够构建可在本地存储的应用程序。虽然它没有像本地存储那样广泛的浏览器支持，但它对于在本地存储非敏感数据仍然很有用。IndexedDB相对于本地存储有一个很大的优势，因为它是一个成熟的数据库，能够处理更多类型的数据。明智地处理数据存储如果谨慎部署，本地存储可以提高站点性能并帮助创建更轻量级的应用程序。但是，本地存储绝不能用于敏感信息，例如密码或个人信息。这样做会带来安全风险。对于需要加密和安全的信息，还有其他高效便捷的解决方案，例如服务器端会话。由于网络安全是一个如此重要的问题，因此没有必要冒险。因此，在使用LocalStorage时要小心。更多Jerry原创文章在这里：《王子熙》：
