localstorage是持久化存储机制，即使关闭浏览器数据也不会丢失。它通过setitem、getitem等方法操作字符串数据，存储对象需先用json.stringify转换，获取时用json.parse解析。区别于sessionstorage，localstorage数据长期存在，适合存储用户偏好设置，而sessionstorage仅在当前会话有效，适合临时数据。使用时需注意：存储容量有限（约5mb），不适合存敏感信息，同步操作可能影响性能，且受同源策略限制。判断是否支持localstorage可通过检测window.localstorage是否存在，并尝试写入和删除数据以确保可用性。
JavaScript的localStorage是一个浏览器提供、用于在客户端持久化存储键值对数据的机制。它的核心特点是，即使浏览器关闭再重新打开，存储的数据也依然存在，不会丢失。它主要用来存储少量非敏感的用户数据，比如用户界面偏好设置、主题选择或者一些离线数据缓存。
存储数据主要通过localStorage对象的几个方法实现。最常用的是setItem(key, value)方法，它允许你将一个键值对保存到localStorage中。需要注意的是，localStorage只能存储字符串类型的数据。如果你想存储JavaScript对象或数组，你需要先用JSON.stringify()将其转换为JSON字符串，取回时再用JSON.parse()解析回来。
// 存储一个简单字符串
localStorage.setItem('username', 'Alice');
console.log(localStorage.getItem('username')); // 输出: Alice
// 存储一个对象（需要先序列化）
const userSettings = {
theme: 'dark',
fontSize: 'medium'
};
localStorage.setItem('settings', JSON.stringify(userSettings));
// 获取并解析对象
const storedSettings = JSON.parse(localStorage.getItem('settings'));
console.log(storedSettings.theme); // 输出: dark
// 移除单个数据
localStorage.removeItem('username');
console.log(localStorage.getItem('username')); // 输出: null
// 清空所有localStorage数据（慎用！）
// localStorage.clear();获取数据则使用getItem(key)方法。如果你需要移除某个键对应的数据，可以使用removeItem(key)。而如果想一次性清除所有存储在当前域下的数据，clear()方法就能派上用场，但这个操作是全局的，所以务必谨慎。
立即学习“Java免费学习笔记（深入）”；
localStorage与sessionStorage有什么区别？
谈到浏览器存储，很多人会自然地想到sessionStorage。它们确实是亲兄弟，用法几乎一模一样，但核心区别在于数据的生命周期。localStorage的数据是持久化的，除非用户手动清除浏览器缓存，或者你的代码主动调用removeItem或clear，否则数据会一直存在。这意味着即使你关闭浏览器，下次再打开同一个网站，之前存的数据还在那儿。这非常适合存储一些不那么敏感、但需要长期保留的用户偏好，比如网站的主题模式、语言设置，或者用户是否已经看过某个新手引导。
而sessionStorage就没那么“长情”了。它的数据生命周期是与当前浏览器会话绑定的。一旦用户关闭了浏览器标签页或窗口，sessionStorage里的数据就会被清空。所以，它更适合存储那些仅在用户当前会话中需要的数据，比如用户在多步表单填写过程中的临时数据，或者一些页面间传递的非敏感状态信息。举个例子，你正在填写一个很长的在线申请表，每一页的数据都可以暂时存在sessionStorage里，这样即使不小心刷新了页面，数据还在，但一旦你完成了提交或者直接关了页面，这些临时数据就没必要保留了。
使用localStorage有哪些注意事项和潜在风险？
虽然localStorage用起来很方便，但它并不是万能药，有些坑还是得提前知道。首先是存储容量问题，它通常只有5MB左右，具体取决于浏览器，所以别指望拿它存大文件，那不现实。它更适合存一些轻量级的配置信息或少量用户数据。
另一个大问题是安全性。localStorage的数据是不加密的，明文存储在客户端，而且很容易被JavaScript访问到。这意味着，如果你的网站存在XSS（跨站脚本攻击）漏洞，恶意脚本就能轻而易举地读取甚至修改localStorage里的所有数据。所以，绝对不要用localStorage来存储用户的敏感信息，比如密码、信用卡号、Session ID等。这些数据应该通过安全的HTTP-only Cookie或者服务器端Session来管理。
再者，localStorage的操作是同步的。这意味着当你调用setItem、getItem等方法时，JavaScript主线程会被阻塞，直到操作完成。对于少量数据，这通常不是问题，但如果你频繁地读写大量数据，或者在主线程中进行复杂的序列化/反序列化操作，就可能导致页面卡顿，影响用户体验。在这种情况下，你可能需要考虑IndexedDB这种异步的、更适合大量结构化数据存储的方案。
最后一点，localStorage是同源策略限制的，也就是说，只有来自同一个域（协议、域名、端口都相同）的页面才能访问到同一份localStorage数据。这既是安全保障，也意味着你不能跨域共享数据。
如何判断浏览器是否支持localStorage？
在实际开发中，你不能想当然地认为所有用户的浏览器都支持localStorage，或者说，即使支持，也可能因为用户开启了隐私模式等原因导致无法正常使用。所以，在使用之前最好做个兼容性检查，这是一种防御性编程的好习惯。
最常见的检查方式是判断window对象上是否存在localStorage属性。但更严谨的做法是，尝试执行一个setItem操作，并用try-catch块捕获可能出现的错误。因为在某些浏览器（比如Safari的隐私模式）中，localStorage对象虽然存在，但当你尝试写入数据时会抛出QuotaExceededError或其他错误。
function isLocalStorageAvailable() {
let test = 'test';
try {
localStorage.setItem(test, test);
localStorage.removeItem(test);
return true;
} catch (e) {
// 这通常发生在隐私模式下，或者存储空间已满
// console.error("localStorage is not available or writeable:", e);
return false;
}
}
if (isLocalStorageAvailable()) {
console.log("localStorage可用！");
// 可以安全地使用localStorage了
} else {
console.log("localStorage不可用，可能处于隐私模式或空间不足。");
// 提供备用方案，比如使用Cookie或提示用户
}通过这种方式，我们可以更健壮地处理localStorage的可用性问题，避免不必要的运行时错误，并可以根据检测结果为用户提供不同的交互体验或降级方案。毕竟，用户体验至上，不是吗？
