LocalStorage是前端持久化存储方案，适合存非敏感、需跨会话保留的数据，通过setItem、getItem、removeItem等API操作，数据以字符串形式存储，复杂类型需JSON序列化。与SessionStorage主要区别在于生命周期：前者长期保存直至手动清除，后者仅限当前标签页会话，关闭即清空，适用于临时数据如表单草稿。选择时依据数据持久性需求：需跨会话保留用LocalStorage，仅当前会话有效则用SessionStorage。使用时注意容量限制（通常5-10MB）、仅支持字符串、明文存储不安全、同步操作阻塞主线程及同源策略限制。其他前端存储方案包括Cookie（小数据、自动随请求发送，用于身份认证）、IndexedDB（大容量、异步数据库，适合离线应用）、Cache API（配合Service Worker缓存网络资源，实现PWA）和内存变量（临时数据）。应根据数据大小、类型、安全性、持久性和共享需求选择合适方案。
HTML5本地存储，也就是我们常说的LocalStorage，其实用起来特别直接。它就像浏览器给你的一个私人小抽屉，你可以把一些不那么敏感、但又想让用户下次访问时还能记住的数据放进去。核心就那么几个API，存、取、删，非常基础，但用好了能解决不少问题。
解决方案
要使用LocalStorage，主要就是围绕着浏览器全局的
localStorage对象来操作。
存数据（setItem） 你需要给数据一个键（key）和一个值（value）。记住，值必须是字符串。如果你想存一个对象或者数组，得先用
JSON.stringify()把它转换成字符串。
// 存一个字符串
localStorage.setItem('username', '张三');
// 存一个数字（会自动转成字符串）
localStorage.setItem('age', 30);
// 存一个对象，需要先JSON.stringify()
const userSettings = {
theme: 'dark',
notifications: true
};
localStorage.setItem('settings', JSON.stringify(userSettings));
// 存一个数组
const recentSearches = ['HTML5', 'CSS Grid', 'JavaScript'];
localStorage.setItem('searches', JSON.stringify(recentSearches));取数据（getItem） 通过之前设置的键名来获取对应的值。取出来的数据也总是字符串。如果之前存的是对象或数组，别忘了用
JSON.parse()把它还原回来。
// 取一个字符串
const username = localStorage.getItem('username'); // '张三'
// 取一个数字（取出来是字符串，需要时可能要parseInt/parseFloat）
const ageStr = localStorage.getItem('age'); // '30'
const age = parseInt(ageStr, 10); // 30
// 取一个对象，需要JSON.parse()
const settingsStr = localStorage.getItem('settings');
if (settingsStr) {
const userSettings = JSON.parse(settingsStr);
console.log(userSettings.theme); // 'dark'
}
// 取一个数组
const searchesStr = localStorage.getItem('searches');
if (searchesStr) {
const recentSearches = JSON.parse(searchesStr);
console.log(recentSearches[0]); // 'HTML5'
}删除单个数据（removeItem） 如果你只想删除某个特定的数据项，就用这个。
localStorage.removeItem('username');清空所有数据（clear） 这个操作会清空当前域名下LocalStorage里的所有数据，慎用。
localStorage.clear();
获取键名（key）和存储数量（length） 有时候你可能想遍历LocalStorage里的所有数据，或者知道它存了多少项。
// 获取存储项的数量
const numberOfItems = localStorage.length; // 比如：2
// 遍历所有键值对
for (let i = 0; i < numberOfItems; i++) {
const key = localStorage.key(i); // 获取第i个键名
const value = localStorage.getItem(key); // 获取对应的值
console.log(`${key}: ${value}`);
}这些就是LocalStorage最核心的用法了，上手真的很快。
LocalStorage和SessionStorage有什么区别？我该怎么选？
这俩兄弟经常被放在一起比较，核心区别就一个字：“命”。
立即学习“前端免费学习笔记（深入）”；
LocalStorage的数据是“长命百岁”的，除非你手动用代码清除，或者用户在浏览器设置里清空了数据，否则它会一直存在。哪怕你关掉浏览器，下次再打开，数据还在那里。我个人觉得，这让它特别适合存储一些用户偏好设置，比如主题模式（深色/浅色）、语言选择、或者一些不敏感的离线数据缓存。想想看，你每次打开一个网站，如果都要重新设置主题，那体验得多糟糕。
每个应用程序都要使用数据，Android应用程序也不例外，Android使用开源的、与操作系统无关的SQL数据库--SQLite，本文介绍的就是如何为你的Android应用程序创建和操作SQLite数据库。 数据库支持每个应用程序无论大小的生命线，除非你的应用程序只处理简单的数据，那么就需要一个数据库系统存储你的结构化数据，Android使用SQLite数据库，它是一个开源的、支持多操作系统的SQL数据库，在许多领域广泛使用，如Mozilla FireFox就是使用SQLite来存储配置数据的，iPhon
SessionStorage则是个“短命鬼”，它的生命周期和当前的浏览器会话（或者说，当前的标签页）绑定。一旦你关闭了这个标签页或者浏览器，SessionStorage里的数据就烟消云散了。它不会在不同的标签页之间共享数据，每个标签页都有自己独立的SessionStorage。这使得它非常适合存储一些临时性的、只在当前会话中需要的数据，比如用户在多步表单中输入了一半的数据，防止页面刷新丢失；或者单页应用（SPA）中一些临时的UI状态。
怎么选呢？ 我的经验是，首先考虑数据的“持久性”需求。
- 如果数据需要在用户关闭浏览器后依然保留，并且希望下次访问时能继续使用，那毫无疑问是LocalStorage。它就像一个永久的便签本。
- 如果数据只是当前会话有效，用户关闭标签页就应该消失，那么SessionStorage是更安全、更合适的选择。它就像一张临时的草稿纸。
- 另外，如果数据需要在不同标签页之间共享，SessionStorage是做不到的，你可能需要考虑LocalStorage或者其他跨标签页通信的方案。
使用LocalStorage时有哪些常见坑和注意事项？
虽然LocalStorage用起来简单，但也有一些需要注意的地方，不然很容易踩坑。
1. 容量限制 首先，它的容量是有限的。通常在5MB到10MB之间，具体取决于不同的浏览器。所以，别指望用它来存储大量的图片、视频或者整个数据库。如果你需要存储大量数据，或者结构更复杂的数据，IndexedDB才是正解。我见过有人想把整个应用的数据都塞进去，结果发现存不进去，或者存进去之后页面变得卡顿，这就是没考虑容量。
2. 只存字符串 这是一个新手经常犯的错误。
setItem方法的值参数只能是字符串。如果你直接传入一个对象或数组，它会悄悄地被转换成
"[object Object]"或者
"array"这样的字符串，而不是你想要的数据结构。取出来的时候，你再
JSON.parse()，就会得到一个解析错误。所以，务必记住，存复杂类型前要
JSON.stringify()，取出来后要
JSON.parse()。这个流程是必须的。
3. 安全性考量 LocalStorage的数据是明文存储的，任何人只要能访问你的浏览器开发者工具，就能轻易地看到、修改这些数据。这意味着：
- 不要存储敏感信息： 密码、用户的身份凭证（如Access Token、Refresh Token）、银行卡号等绝对不能存在LocalStorage里。一旦用户的电脑被攻破或者浏览器被劫持，这些信息就可能泄露。
- XSS风险： 如果你的应用从LocalStorage读取数据并直接渲染到页面上，而这些数据又来自不可信的用户输入，那么就存在跨站脚本（XSS）攻击的风险。攻击者可以注入恶意脚本，然后存储到LocalStorage，下次页面加载时执行。始终对从LocalStorage取出的数据进行必要的清理和转义。
4. 同步操作 LocalStorage的所有操作都是同步的。这意味着当你调用
setItem、
getItem等方法时，JavaScript主线程会被阻塞，直到操作完成。对于少量数据读写，这通常不是问题。但如果你在短时间内进行大量的LocalStorage操作，或者存储的数据量相对较大，就可能导致页面卡顿，影响用户体验。在这种情况下，异步的IndexedDB会是更好的选择。
5. 同源策略 LocalStorage受到浏览器的同源策略限制。也就是说，只有在同一个协议、同一个域名、同一个端口下的页面，才能访问彼此的LocalStorage数据。比如，
http://www.example.com和
https://www.example.com的LocalStorage是隔离的，
www.example.com和
sub.example.com的LocalStorage也是隔离的。这在大多数情况下是安全的保障，但有时也会给跨子域的数据共享带来一些麻烦。
除了LocalStorage，前端还有哪些数据存储方案，各自适用于什么场景？
LocalStorage只是前端数据存储工具箱里的一把锤子，但它不是唯一的工具，也不是万能的。根据不同的需求，我们还有其他一些选择：
1. Cookie 这是最古老也最常用的前端存储方式之一。
- 特点： 容量非常小（通常4KB），可以设置过期时间，最重要的是，它会随着每个HTTP请求自动发送到服务器。
- 场景： 最主要用于会话管理（比如用户登录状态），也可以用来存储一些非常小的、需要发送给服务器的用户偏好设置。由于它每次请求都会携带，所以不适合存储大量数据，否则会增加网络开销。
2. SessionStorage 前面已经提过了，它是LocalStorage的“短命版”。
- 特点： 和LocalStorage API类似，但数据只在当前会话（标签页）有效，关闭标签页即清除。
- 场景： 临时会话数据、多步表单数据暂存、单页应用中一些不需要持久化的UI状态。
3. IndexedDB 这是一个浏览器内置的、功能强大的客户端数据库。
- 特点： 这是一个非关系型（NoSQL）数据库，容量巨大（几十MB到几GB），支持事务，异步操作，可以存储结构化数据，甚至二进制数据。它的API相对复杂，学习曲线比LocalStorage陡峭。
- 场景： 离线应用（PWA）、需要存储大量结构化数据、需要进行复杂查询、希望数据在Web Worker中可用。如果你正在构建一个需要强大离线能力的复杂应用，IndexedDB几乎是唯一的选择。
4. Cache API (配合Service Worker) 这个API主要用于缓存网络请求的响应。
- 特点： 通常与Service Worker一起使用，可以拦截网络请求，并返回缓存的响应，从而实现离线访问和更快的加载速度。
- 场景： 渐进式Web应用（PWA）、离线优先策略、静态资源（图片、CSS、JS文件）的缓存。它侧重于缓存网络资源，而不是任意的用户数据。
5. 全局变量/内存存储 最简单直接的方式，就是把数据存在JavaScript的变量里。
- 特点： 数据只存在于当前页面的内存中，页面刷新、关闭就会丢失。
- 场景： 临时数据、组件间通信、不需要持久化的UI状态。它最快，但生命周期最短。
我个人觉得，选择哪种存储方案，关键在于理解你的数据特性和业务需求。
- 对于简单、少量、非敏感且需要持久化的数据，LocalStorage是首选，它足够简单高效。
- 如果数据量大、结构复杂、或者需要强大的离线能力，那肯定得是IndexedDB。
- 会话管理和少量需要与服务器交互的数据，Cookie仍然是不可替代的。
- 而Cache API和Service Worker，则是构建高性能、离线可用PWA的基石。
没有哪个方案是完美的，它们各有优缺点，关键在于根据场景做出最合适的选择。
