HTML5本地存储是什么？localStorage使用教程

HTML5的localStorage是一种强大而便捷的客户端持久化存储方案，它允许网页在用户浏览器中安全地保存大量（5–10MB）键值对数据，且数据长期存在、不随HTTP请求发送，显著优于传统Cookie的小容量与高网络开销；通过setItem/getItem等简洁API即可操作，配合JSON序列化可轻松处理对象数据，但需警惕XSS风险、数据类型限制、同步阻塞及同源策略等实际陷阱——掌握这些特性，你就能在记住用户偏好、缓存离线内容等场景中高效提升体验与性能。

localStorage是HTML5提供的本地存储方案，它允许在客户端持久化存储键值对数据，且不会随HTTP请求发送，相比Cookie具有更大容量（5-10MB）和更简单的API操作；1. 存储数据使用setItem()，但只能存储字符串，复杂数据需通过JSON.stringify()序列化；2. 获取数据使用getItem()，对应需用JSON.parse()还原对象；3. 删除单个数据用removeItem()，清空全部用clear()；4. 可通过length和key()遍历存储内容；5. 与sessionStorage的区别在于生命周期，localStorage数据长期存在，除非手动清除，而sessionStorage仅在当前会话有效，关闭标签页即消失；6. 相比Cookie，localStorage不自动发送到服务器，减少网络开销，且容量更大、操作更简便，但安全性较低，易受XSS攻击，因此不应存储敏感信息；7. 使用时需注意数据类型限制、同步阻塞主线程、存储空间上限及同源策略限制，合理选择存储方案以提升性能与安全。

HTML5本地存储，简单来说，就是浏览器提供给网页的一种在用户本地保存数据的能力。它不像传统cookie那样容量小、每次请求都带到服务器，而是允许我们直接在客户端存储更多数据，并且这些数据是持久化的，除非用户手动清除，否则它们会一直存在。而localStorage，就是这套本地存储机制里最常用、也最直接的一个工具。

解决方案

操作localStorage其实非常直观，它提供了一套简单的API，就像在操作一个键值对（key-value pair）的字典。

要往里面存数据，我们用setItem()。比如你想保存一个用户的名字：

localStorage.setItem('userName', '张三');

这里需要注意的是，localStorage存储的所有数据都是字符串。如果你尝试存储一个对象或者数组，它会自动被转换成字符串[object Object]或1,2,3这样的形式，这显然不是我们想要的。所以，如果想存复杂数据结构，我们通常会先用JSON.stringify()把它序列化成JSON字符串，取出来的时候再用JSON.parse()解析回来。

const userProfile = {
    name: '李四',
    age: 30,
    city: '北京'
};
localStorage.setItem('userProfile', JSON.stringify(userProfile));

// 取出来的时候
const storedProfile = JSON.parse(localStorage.getItem('userProfile'));
console.log(storedProfile.name); // 输出：李四

取数据呢，就用getItem()：

const name = localStorage.getItem('userName');
console.log(name); // 输出：张三

如果你想删除某个特定的数据项，removeItem()就派上用场了：

localStorage.removeItem('userName');

要是想把当前域名下localStorage里存的所有东西都清空，那直接用clear()：

localStorage.clear(); // 小心使用，这会清空所有数据！

有时候，你可能想知道localStorage里存了多少条数据，或者遍历一下所有键。length属性可以告诉你总数，key()方法则可以根据索引获取键名：

for (let i = 0; i < localStorage.length; i++) {
    const key = localStorage.key(i);
    const value = localStorage.getItem(key);
    console.log(`${key}: ${value}`);
}

在我看来，localStorage用起来就是这么简单，但它的威力却不小，很多时候能大大提升用户体验，比如记住用户的偏好设置、离线缓存一些不常变动的数据等等。

localStorage和sessionStorage有什么区别？

这是个经常被问到的问题，而且确实很重要，因为它决定了你的数据“活”多久。localStorage和sessionStorage都属于Web Storage API，操作方法几乎一模一样，但它们的核心区别在于数据的生命周期。

localStorage的数据是持久化的。这意味着一旦数据被存储，它会一直保留在用户的浏览器中，即使浏览器关闭、电脑重启，甚至用户清除了浏览器缓存（当然，如果用户专门清除了本地存储，那数据就没了）。它没有过期时间，除非你手动用removeItem()或clear()去删除，或者用户自己去浏览器设置里清空。这非常适合存储那些需要长期保留的数据，比如用户的登录状态（尽管实际应用中登录token通常有过期时间，但可以用localStorage来存）、主题偏好、上次访问的页面等等。

而sessionStorage的数据生命周期就短得多了。它的数据只在当前浏览器会话（session）有效。什么叫一个会话呢？简单理解，就是从你打开一个浏览器标签页或窗口开始，到你关闭这个标签页或窗口为止。如果你在一个标签页里存了数据，然后打开一个新的标签页（即使是同一个网站），新标签页里是访问不到旧标签页的sessionStorage数据的。而且，一旦你关闭了那个标签页或窗口，sessionStorage里的数据就全部被清除了。所以，它更适合存储那些临时性的、只需要在用户当前操作流程中保持的数据，比如表单填写过程中的草稿、多步操作的中间状态等。

选择哪个，完全取决于你的数据需要“活”多久，以及它是否需要跨标签页共享。

为什么在实际项目中，我们有时会优先考虑localStorage而不是传统的Cookie？

这确实是个值得深思的问题，毕竟Cookie存在了这么久，为什么现在很多场景下会转向localStorage呢？这背后有几个关键的原因。

一个最直接的考量就是存储容量。传统的Cookie，每个域名下的存储容量非常有限，通常只有4KB左右。这对于存储一些简单的用户ID、session ID之类的还好，但如果你想在客户端缓存一些稍微复杂的数据，比如用户配置、离线数据，4KB就显得捉襟见肘了。localStorage在这方面就大方多了，它提供了远超Cookie的存储空间，通常在5MB到10MB之间（具体取决于浏览器），这足以满足绝大多数前端应用的数据缓存需求。

其次是性能和网络负载。Cookie有一个“烦人”的特性，就是它每次HTTP请求都会自动携带到服务器。这意味着，即使你的数据只在客户端使用，每次向服务器发送请求时，这些Cookie数据也会被上传。当Cookie数量多或体积大时，这会增加网络流量，影响请求性能。localStorage则完全是客户端的，它的数据不会随着HTTP请求自动发送到服务器。只有当你明确地通过JavaScript代码将数据发送到服务器时，它才会被传输。这对于减轻服务器压力、提升前端应用响应速度来说，是个不小的优势。

再者是API的易用性。操作localStorage的API非常简单直观，就是setItem、getItem、removeItem、clear。而Cookie的操作相对来说就复杂一些，你需要手动处理字符串解析、过期时间、路径等各种属性，或者依赖第三方库。从开发效率和维护成本来看，localStorage更胜一筹。

当然，Cookie也有它不可替代的优势，比如它天生支持服务器设置HttpOnly来防止XSS攻击获取，以及通过Secure属性强制HTTPS传输，还有SameSite属性来缓解CSRF攻击。localStorage的数据虽然容量大、操作方便，但它完全通过JavaScript访问，这就意味着如果你的网站存在XSS漏洞，攻击者可以轻易地通过JavaScript获取到localStorage里存储的所有数据。所以，对于敏感信息，比如用户的认证Token，通常会结合使用Cookie（HttpOnly）和localStorage，或者干脆只用HttpOnly的Cookie。

在我看来，选择哪种存储方式，最终还是取决于数据的性质、安全要求以及应用场景。localStorage更适合存储非敏感的、需要大容量、长期持久化且主要在客户端使用的数据。

使用localStorage时，有哪些常见的陷阱或需要注意的问题？

尽管localStorage用起来非常方便，但它并非完美无缺，实际使用中确实有一些需要特别留心的地方，不然可能会踩到一些坑。

一个很常见的误区是存储的数据类型。我前面提到过，localStorage只能存储字符串。如果你直接localStorage.setItem('myObject', {a: 1})，你取出来会发现得到的是字符串[object Object]，而不是你想要的对象。解决办法当然是使用JSON.stringify()和JSON.parse()，但这要求你的数据必须是JSON可序列化的。如果你的对象里包含函数、Date对象、undefined等非JSON原生类型，JSON.stringify()可能会把它们忽略或转换成其他形式，导致数据丢失或变形。比如，Date对象会被转换成ISO格式的字符串，取出来后需要手动new Date()转换回去。

安全性问题也是一个大头。localStorage的数据是明文存储的，并且可以通过任何运行在同源页面上的JavaScript代码访问。这意味着，如果你的网站存在XSS（跨站脚本攻击）漏洞，攻击者可以注入恶意JavaScript代码，轻而易举地读取甚至篡改localStorage中的所有数据。所以，绝对不要在localStorage中存储敏感的用户信息，比如密码、信用卡号，或者未经加密的认证Token。对于认证Token，更好的做法是使用HttpOnly的Cookie，或者将其存储在内存中，并设置较短的过期时间。

再来就是同步操作的问题。localStorage的所有操作（setItem, getItem等）都是同步的，这意味着它们会阻塞主线程。虽然对于小量数据读写来说，这点延迟几乎可以忽略不计，但如果你尝试存储或读取大量数据（比如几MB），这可能会导致页面出现短暂的卡顿，影响用户体验。在一些对性能要求极高的场景下，这可能需要你考虑使用IndexedDB等异步存储方案。

存储空间限制虽然比Cookie大很多，但也不是无限的。通常是5MB到10MB，具体取决于浏览器和用户设置。如果你的应用尝试存储超过这个限制的数据，localStorage.setItem()会抛出一个QuotaExceededError。所以，在存储数据前，最好能预估一下数据量，并在必要时进行清理或压缩。

最后，一个容易被忽视的点是跨域问题。localStorage是严格遵守同源策略的。这意味着，http://example.com存储的数据，http://sub.example.com、https://example.com或http://another-domain.com都无法直接访问。即使是同一个域名，如果协议或端口不同，也算作不同的源。这在开发过程中，特别是涉及多个子域或不同环境时，需要特别注意。

在我看来，理解这些“坑”不是为了避免使用localStorage，而是为了更明智、更安全地利用它。它是一个非常实用的工具，但就像任何工具一样，了解它的局限性才能更好地发挥它的作用。

以上就是《HTML5本地存储是什么？localStorage使用教程》的详细内容，更多关于的资料请关注golang学习网公众号！