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
，而是为了更明智、更安全地利用它。它是一个非常实用的工具，但就像任何工具一样，了解它的局限性才能更好地发挥它的作用。
评论（已关闭）
评论已关闭