这是一个范围极为广泛的问题，很多利弊都取决于具体情况。

在所有情况下，这些存储机制都将特定于单个计算机/设备上的单个浏览器。跨会话持续存储数据的任何要求都将涉及您的应用服务器端-
最有可能使用数据库，但可能使用XML或文本/ CSV文件。

localStorage，sessionStorage和cookie都是客户端存储解决方案。会话数据保存在您直接控制的服务器上。

localStorage和sessionStorage

localStorage和sessionStorage是相对较新的API（意味着，并非所有旧版浏览器都支持它们），并且几乎完全相同（API和功能都相同），唯一的例外是持久性。sessionStorage（顾名思义）仅在浏览器会话期间可用（并在关闭选项卡或窗口时删除）-但是，它确实可以在页面重新加载后幸存）。

显然，如果需要持续提供要存储的数据，则localStorage比sessionStorage更可取-
尽管您应注意两者都可以被用户清除，所以在任何一种情况下都不应依赖于数据的持续存在。

localStorage和sessionStorage非常适合在页面之间的客户端脚本中持久存储所需的非敏感数据（例如：偏好，游戏中的得分）。可以轻松地从客户端/浏览器中读取或更改存储在localStorage和sessionStorage中的数据，因此不应依赖它们在应用程序中存储敏感或与安全相关的数据。

cookie

对于cookie来说也是如此，用户可以对其进行微不足道的篡改，并且还可以纯文本格式从中读取数据-
因此，如果您要存储敏感数据，则会话实际上是您唯一的选择。如果您未使用SSL，则cookie信息也可能在传输过程中被截获，尤其是在开放的wifi上。

从积极的方面来说，通过设置仅HTTP标志，cookie可以受到一定程度的保护，免受跨站点脚本（XSS）/脚本注入等安全风险的影响，这意味着现代（支持）浏览器将阻止访问JavaScript和来自JavaScript的值（这也将阻止您自己的合法JavaScript访问它们）。这对于身份验证cookie尤其重要，身份验证cookie用于存储包含登录用户详细信息的令牌-
如果您具有该cookie的副本，那么就所有意图和目的而言，您将 成为 该用户，直至该Web应用程序为止。并具有与用户拥有的数据和功能相同的访问权限。

由于Cookie用于身份验证目的和用户数据的持久性，因此针对同一域的 每个 请求都会将针对页面有效的 所有
cookie从浏览器发送到服务器-这包括原始页面请求，任何后续的Ajax请求，所有图像，样式表，脚本和字体。因此，cookies不应用于存储大量信息。浏览器还可能会限制可存储在Cookie中的信息的大小。通常，cookie用于存储身份验证令牌，以进行身份​​验证，会话和广告跟踪。令牌本身通常不是人类可读的信息，而是链接到您的应用程序或数据库的加密标识符。

localStorage vs.sessionStorage vs.Cookie

就功能而言，Cookie，sessionStorage和localStorage仅允许您存储字符串-
设置时可以隐式转换原始值（读取后将这些原始值转换回使用它们作为它们的类型），但不允许对象或数组（可以对JSON进行序列化以使用API​​进行存储）。会话存储通常将允许您存储服务器端语言/框架支持的任何原语或对象。

客户端与服务器端

由于HTTP是一种无状态协议，Web应用程序无法从返回网站的先前访问中识别用户-
会话数据通常依赖于Cookie令牌来标识用户进行重复访问（尽管很少有URL参数可用于相同的目的）。数据通常会有一个有效期的到期时间（每次用户访问时都会更新），并且取决于您的服务器/框架，数据将在过程中存储（这意味着数据将在Web服务器崩溃或重新启动时丢失）或在外部存储。状态服务器或数据库。使用网络农场（给定网站有多个服务器）时，这也是必要的。

由于会话数据完全由您的应用程序（服务器端）控制，因此它是任何敏感或安全性质的最佳场所。

服务器端数据的明显缺点是可伸缩性-
会话期间每个用户都需要服务器资源，并且客户端必须与每个请求一起发送任何所需的数据。由于服务器无法知道用户是导航到另一个站点还是关闭其浏览器，因此会话数据必须在给定时间后过期，以避免所有服务器资源被废弃的会话占用。因此，在使用会话数据时，您应该意识到数据可能已经过期并丢失的可能性，尤其是在长格式页面上。如果用户删除其cookie或切换浏览器/设备，它也将丢失。

一些Web框架/开发人员使用隐藏的HTML输入来将数据从表单的一个页面持久保存到另一页面，以避免会话过期。

localStorage，sessionStorage和cookie均受“同源”规则的约束，这意味着浏览器应阻止访问数据（除了设置信息开头的域之外）。