localStorage vs sessionStorage vs Cookies – 详细比较

Cookie 已经存在很长时间了（Internet Explorer v2 于 1995 年 10 月支持它们）。 它们没有任何问题，它们确实让网络变得更令人愉快，但近 25 年后发生了很多变化。

本地存储（您可以在 W3 的 Web 存储下找到它）是也不是 cookie 的替代品。 这就是它最令人困惑的地方。 在大多数情况下，您可以安全地使用 localStorage 而不是 cookie，并获得（错误的）印象，即它们是相同的，而实际上它们不是。 继续阅读以了解如何以及何时使用 localStorage 替换 cookie 的严肃细分。

革命还是进化？

本地存储，或 localStorage，或 DOM 存储或 Web 存储（我没有编造这些名称；所有这些都在使用，并且都引用相同的东西）在 2012 年作为“HTML5”在流行浏览器中被实际采用特征”。 这似乎是饼干的天赐之物。 修复了一直携带不需要的数据的臃肿请求和大小限制。 虽然它确实“解决”了这些问题，但它并不是饼干的苹果换苹果替代品。

当我们讨论不需要的数据时。 您是否知道请求并不是唯一会导致不必要的膨胀的东西，您的网站也可以。 幸运的是，有一个解决方案，它被称为 WP Reset。

WP Reset 是一个带有一系列重置选项的插件，可让您执行诸如从您的站点中删除累积的数据和/或附加组件（插件、主题、用户、小部件、内容等）等操作，以及甚至将整个网站擦干净。 很神奇，对吧？ 但这还不是全部。 除其他功能外，此插件可以创建数据库快照以及插件和主题集合，您可以根据需要多次单击安装它们。 绝对是值得一试的工具。

但是，现在，让我们回到讨论 localStorage。

顾名思义，数据存储在本地，在用户的设备上。 因此，它不必通过网络传输每个 HTTP 请求，从而减少占用空间并为我们提供更多空间来保存数据。 “仅限本地”范式是 cookie 和本地存储之间最显着的区别。 Cookies 可以在服务器端和客户端读取，本地存储只能在客户端。 这里的所有都是它的。 如果您的应用程序严重依赖于读取服务器端 cookie 并基于它生成内容，那么切换到本地存储将意味着重写应用程序。 如果您只使用 cookie 来存储设置，例如界面中哪个选项卡处于活动状态，那么本地存储是一个理想的替代品。

看似相似

下表清晰地展示了 cookie、localStorage 和 sessionStorage 的区别和用例。 虽然您可以快速浏览它以获得所需的答案并离开，但我建议您阅读一些冗长的脚注，其中包含更多细节。 是的，我知道你很忙，想观看下一个猫视频，但事情不是非黑即白的，所以深入挖掘会对你有好处。

深入挖掘网络存储和 cookie

您可以在本地存储的最大数据量取决于浏览器。 没有任何保证，如果您想要一个安全的赌注，请低于 5 MB 到大约 2 MB。 使用这个方便的工具来测试浏览器中允许的最大本地存储大小。

用户阻止第 3 方或所有 cookie是一种常见情况。 相同的规则适用于本地存储。 没有任何保证，您的应用程序必须在本地存储不可用的环境中工作（或至少不中断）。

所有cookie 都会在某个时候过期，但人们倾向于将生命周期设置为几年，这在互联网时代似乎是永远的。 另一方面，本地存储永远不会过期，并且在应用程序或用户删除它之前可用。 关闭选项卡或窗口时，会话存储将被清除 - 没有例外。

“你的意思是只能保存字符串？ 我一直在保存物品！” JSON 使您能够以字符串的形式保存对象和其他数据类型。 转换是在您不知情的情况下通过阅读和写作完成的。 有了用于处理 cookie 和本地存储的健全库，您就不必考虑数据类型。 但是，这并没有改变仅原生支持字符串的事实。

没有一个客户端功能是所有浏览器都支持的。 这是一个可悲的事实，但仍然是事实。 您可以在 Can I Use 上查看具体数字，但就 cookie 和本地存储而言，我会忽略所有不支持它们的浏览器。 它们是边缘的，低于 1%。

您不能仅通过服务器端处理访问 localStorage。 你也需要JS。 当用户请求一个页面并且 PHP 启动（或您使用的任何服务器端语言）来生成它时，您将无法访问任何本地数据、会话或永久数据。 一旦页面加载并且 JS 启动，您就可以访问本地数据并做任何您需要的事情 - 调整用户界面或利用 AJAX 将本地数据发送回服务器。 所以是的，您可以将本地数据返回到服务器，但与使用 cookie 的方式和时间不同。 根据您的要求，在从 cookie 切换到本地存储时，这可能会破坏交易，所以，请 - 提前计划！

使用本地存储，客户端和服务器之间不会传输任何数据（除非有明确的代码）。 这对于减小有效载荷大小非常有用。 另一方面，Cookie 会作为 HTTP 标头字段与设置域上的每个请求一起传输。 这无法更改或有选择地关闭。

用户“不应该”访问本地数据并直接更改它（在您的应用程序之外），但没有什么能阻止他们这样做。 有许多调试工具可用于编辑本地存储的数据。 所以不要相信本地数据或假设用户没有触摸它。 总是假设更糟。

虽然cookie 确实具有您可以设置的“安全”属性，但这并不能保护从应用程序传输到浏览器的 cookie。 所以总比没有好，但远非安全。 本地存储是一种仅限客户端的技术，它不知道也不关心您使用的是 HTTP 还是 HTTPS。 安全性必须来自您处理数据的方式。 不要在任何形式的本地存储中存储任何敏感数据，例如信用卡号或密码！ 曾经！

一些代码让你开始

这篇文章并不是一个 JavaScript 网络存储教程，而是为了省去你的麻烦，这里有一个带有本地存储的 Hello World 示例；

// store a value
localStorage.setItem( 'name', 'John' );

// retrieve a value
localStorage.getItem( 'name' );

// remove the value
localStorage.removeItem( 'name' );

// only string values can be stored so for objects, use JSON
var post = {
  title: 'Cookies are old',
  author: 'Gordan'
}
localStorage.setItem( 'post', JSON.stringify( post ) );

// and to retrieve
var post = JSON.parse( localStorage.getItem( 'post' ) );

上面的代码有效，并且尽可能简单。 但是，我不建议使用它。 与 cookie 一样，没有人使用document.cookies与它们进行交互。 需要考虑一些小的跨浏览器差异，并且由于它们只存储字符串，因此您必须在每次读取和写入时使用 JSON 进行字符串化和解析。 这就是我们使用小型库来帮助我们处理 js-cookie 等 cookie 的原因。 本地存储也是如此。 从长远来看，在代码和 API 之间放置一个小的抽象层会有所帮助。 我推荐 store.js。 它已经存在了一段时间，负责处理跨浏览器的废话和后备问题，甚至还有方便的插件来扩展其功能。 如果您对一些编码练习感兴趣，请创建自己的库并将其转换为 jQuery 插件。

饼干很糟糕，对吧？ 我们需要一些新的东西！

饼干还不错。 几十年来，他们一直在为自己的目标服务，并将继续这样做，因为本地存储不是“以苹果换苹果”的替代品。 然而，饼干显示出老化的迹象。 除此之外，他们的一些设计缺陷也不会很快消失。 即使用 cookie 有效负载和较小的最大有效负载大小“污染”域上的每个请求。

cookie 是否不足和是否陈旧，都将继续存在，因此不要认为本地存储会很快完全接管。 但是，在某些用例中，本地存储无疑是更好的选择。

如果您有（大量）数据要存储在客户端，而这些数据很少传输到服务器，并且这些数据不包含任何敏感信息 -开始使用本地存储！ 这正是它的创建目的。 您将通过减轻域上的所有 HTTP 请求来创建更快的应用程序，并获得使用新事物的温暖模糊感觉。