常见本地存储方案：各自的”脾气”和适用场景
刚开始做前端的时候，我以为本地存储就只有localStorage和sessionStorage，直到有次接手一个老项目，发现代码里全是操作Cookie的逻辑，当时还吐槽”都什么年代了还用Cookie“，后来才明白每种方案都有它不可替代的场景。下面我一个一个给你掰扯清楚，你可以对号入座看看自己项目适合哪种。
先说Cookie，这算是本地存储里的”老大哥”了，从Web诞生初期就存在。它的特点是小而精，单个Cookie最多存4KB数据，而且会随着每次HTTP请求发送到服务器。我之前做一个后台管理系统，用户登录后需要验证身份，这时候Cookie就派上用场了——服务器把token存在Cookie里，前端每次发请求自动带上，不用手动写代码传递。不过Cookie有个麻烦事，就是生命周期需要手动设置，默认关闭浏览器就没了，得用expires或max-age参数指定过期时间。另外它的安全性配置也挺重要，比如设置HttpOnly可以防止XSS攻击获取Cookie，Secure属性确保Cookie只在HTTPS下传输，这些都是我踩过坑后才重视的细节。
然后是localStorage，这应该是前端最常用的存储方案了吧？我第一次用它是做一个个人博客的主题切换功能，用户选了深色模式，用localStorage存一个theme: 'dark'，下次打开网站就读这个值，自动应用主题，当时觉得特别方便。它的优点很明显：持久化存储（除非手动删除或清理浏览器数据）、容量比Cookie大（一般5MB）、API简单（setItem/getItem/removeItem），完全够用。但你可能不知道，localStorage有个坑——它只能存字符串！如果你要存对象，得先用JSON.stringify()转成字符串，取出来再JSON.parse()，有次我忘了转，存了个对象进去，结果取出来是"[object Object]"，调试了半天才发现。还有，localStorage是同步操作，如果频繁读写大量数据，可能会阻塞主线程，导致页面卡顿，我之前做一个数据可视化页面，每秒往localStorage存一次数据，结果页面卡得不行，后来改成定时批量存储才解决。
sessionStorage
和localStorage很像，API都一样，但生命周期不同——它只在当前会话有效，关闭标签页就没了。这个特性特别适合存临时数据，比如用户正在填写的表单。我之前帮一个朋友做过一个长表单页面，用户填了好几页，万一不小心刷新或者误关页面，数据就全没了。后来我用sessionStorage实时保存表单数据，用户每填完一项就存一次，就算刷新页面，再用getItem把数据读出来回填，用户体验立马提升了不少。不过要注意，sessionStorage是按标签页隔离的，同一个网站开两个标签页，它们的sessionStorage互不影响，这一点和Cookie、localStorage不同，你设计的时候得考虑到。
最后是IndexedDB，这个可能用的人不多，但处理大量结构化数据时它是真的香。我去年做一个离线文档编辑工具，需要存用户的多篇文档内容、修改历史、标签分类，这时候localStorage的5MB就不够用了，IndexedDB的优势就体现出来——理论上容量没有上限（取决于硬盘空间），支持复杂查询、事务、索引，完全就是个本地数据库。不过它的API确实有点复杂，异步操作、需要监听各种事件（onupgradeneeded/onsuccess/onerror），我刚开始学的时候绕了不少弯。记得第一次用它存文档，写了个打开数据库、创建对象仓库、添加数据的流程，结果忘了写事务提交，数据死活存不进去，后来查MDN文档才发现，IndexedDB的写操作必须在事务里执行。如果你需要做离线应用、本地日志存储、或者大量数据缓存（比如电商APP的商品列表缓存），IndexedDB绝对是首选，虽然学习成本高一点，但用熟了真的离不开。
为了让你更直观对比，我整理了一个表格，把这四种方案的关键指标列出来，你可以根据项目需求直接对照选择：
| 存储方案 | 容量 | 生命周期 | 适用场景 | 注意事项 |
|---|---|---|---|---|
| Cookie | 4KB | 可设置过期时间（默认会话级） | 身份验证、用户追踪、小数据传递 | 需设置HttpOnly/Secure属性防攻击 |
| localStorage | 约5MB | 永久存储（除非手动删除） | 用户偏好、主题设置、离线数据缓存 | 仅存字符串，同步操作可能阻塞主线程 |
| sessionStorage | 约5MB | 会话级（标签页关闭后删除） | 临时表单数据、单页面应用状态管理 | 不同标签页数据不共享 |
| IndexedDB | 无上限（取决于硬盘） | 永久存储 | 大量结构化数据、离线应用本地数据库 | API复杂，异步操作，支持事务和索引 |
（表格数据参考：MDN Web Storage API 文档 和 Google Developers IndexedDB 指南）
按需求选方案：3个关键维度帮你做决策
知道了每种方案的特点，接下来就是怎么选了。我见过很多新手上来就用localStorage，觉得”万能”，结果项目复杂后各种问题。其实选存储方案就像挑工具，没有最好的，只有最合适的。我 了三个关键维度，你可以一步步对照，基本就能选对了。
维度一：数据”大小”和”类型”说了算
首先看你要存多少数据，是什么类型。如果是小数据（几KB以内），比如用户ID、主题偏好、是否记住登录状态，优先考虑Cookie或localStorage。我之前做一个音乐播放器的”最近播放”列表，只存10首歌的ID和播放时间，每条数据不到100字节，用localStorage存刚刚好，JSON.stringify后也就1KB左右，完全不占空间。但如果你要存大量数据，比如用户上传的图片（base64格式）、离线地图的瓦片数据、或者几百条商品信息，那5MB的localStorage肯定不够，这时候IndexedDB就是更好的选择。我去年做一个离线版的产品手册APP，需要存500多页的图文内容，用IndexedDB建了一个articles仓库，按章节和关键词建索引，用户离线时也能快速搜索和浏览，体验和在线没区别。
数据类型也很重要。如果是简单的键值对（比如username: '张三'），localStorage足够；如果是结构化数据（比如包含嵌套对象、数组的复杂数据），IndexedDB支持对象存储，不用手动JSON转换，用起来更方便。比如存用户的订单信息，包含订单号、商品列表、收货地址、支付状态，这些字段用IndexedDB的对象仓库存储，查询时直接按订单号或日期过滤，比localStorage存一堆JSON字符串再手动解析高效多了。
维度二：数据要”活多久”？临时还是永久？
第二个要考虑的是数据的生命周期。如果你需要数据在用户关闭浏览器后还能保留（比如记住用户的登录状态、保存购物车商品），那localStorage或IndexedDB是首选；如果只是临时数据，用户关闭标签页就可以删除（比如表单的临时草稿、单页面应用的路由历史），sessionStorage更合适。我之前做一个在线考试系统，考生答题时需要实时保存答案，但考试结束后数据就没用了，用sessionStorage正好，考生不小心关闭页面，重新打开还能恢复之前的答题进度，考完关闭标签页数据自动清除，不用手动删除。
这里有个小技巧：有时候你可能需要”半持久化”存储——数据既要长期保存，又怕用户清理浏览器数据丢失。这时候可以用”双保险”策略，比如把关键数据同时存在localStorage和Cookie里，读取时先读localStorage，如果没有再读Cookie恢复。我做过一个用户自定义导航的功能，用户拖拽调整导航顺序后，用localStorage存主要配置，同时用Cookie存一个精简版的备份（只存导航ID和顺序），后来真的有用户反馈”清理缓存后导航乱了”，这时候Cookie的备份就派上用场了，自动恢复了用户的配置，用户还特地来感谢我，说体验很贴心。
维度三：安全和性能”底线”在哪里？
也是最容易被忽略的——安全性和性能。先说安全，本地存储的数据都存在用户浏览器里，不是绝对安全的！特别是localStorage，任何前端脚本都能访问，万一页面有XSS漏洞，攻击者就能轻松获取里面的数据。所以敏感数据（比如密码、token、银行卡信息）绝对不要直接存在localStorage里！我见过有人图方便，把用户的登录token存在localStorage，结果被XSS攻击盗取，导致账号被盗。正确的做法是：敏感数据用Cookie存，并设置HttpOnly和Secure属性，或者加密后再存localStorage（比如用AES加密，密钥存在服务端）。我现在做项目，只要涉及用户身份信息，都会先用CryptoJS加密，再存localStorage，密钥通过接口动态获取，相对安全一些。
性能方面，localStorage和sessionStorage是同步API，读写操作会阻塞JavaScript主线程。如果你在循环里频繁读写localStorage，页面可能会卡顿。我之前做一个实时日志展示功能，每秒往localStorage存一次日志，结果页面帧率从60掉到30，后来改成每10秒批量存储一次，性能立刻恢复了。而IndexedDB是异步API，所有操作都在后台线程执行，不会阻塞主线程，适合大量数据的读写。但IndexedDB的API比较复杂，上手成本高，如果你团队都是新手，也可以考虑用一些封装好的库（比如localForage，它封装了IndexedDB、localStorage等，自动选择合适的存储方式，API和localStorage一样简单），我带新人时就推荐他们先用localForage，熟悉后再学原生IndexedDB。
还有一个容易踩的坑：浏览器的”隐私模式”。在Safari的隐私浏览模式下，localStorage虽然能用，但数据会存在内存里，关闭标签页就删除，而且可能有容量限制；IndexedDB在部分浏览器的隐私模式下甚至会禁用。所以你写代码时一定要做好兼容处理，比如用try-catch包裹存储操作，失败时降级到其他方案或提示用户。我之前做一个表单工具，在Safari隐私模式下localStorage写入失败，页面直接白屏，后来加了捕获：try { localStorage.setItem(key, value) } catch(e) { alert('当前浏览器模式不支持本地存储，请关闭隐私模式后重试') }，才解决问题。
其实选本地存储方案没那么复杂，你只要记住：小数据、临时用sessionStorage，小数据、永久用localStorage，需和服务器交互用Cookie，大量/结构化数据用IndexedDB。如果你还是拿不准，可以先从小方案试起，比如先用localStorage实现，遇到容量或性能问题再升级到IndexedDB，毕竟迭代优化比一开始就过度设计更实际。
对了，如果你有特别的场景（比如PWA离线应用、跨域存储需求），可能还需要考虑Service Worker结合CacheStorage，但那就是更进阶的内容了。你最近在做的项目有用到本地存储吗？遇到了什么问题？可以在评论区告诉我，我们一起看看怎么解决！
你肯定遇到过这种情况：在网站上切换了深色模式，关了浏览器第二天再打开，发现还是深色模式——这就是localStorage在起作用。它的“脾气”就是“记仇”，只要你不手动删，数据能一直存在浏览器里，哪怕电脑重启都没事。我之前帮朋友做个人博客时，用户选了“默认显示最新文章”的设置，就是用localStorage存了个preferLatest: true，用户关了浏览器再访问，页面加载时就读这个值，自动跳转到最新文章列表，体验特别顺畅。
但sessionStorage就不一样了，它是“临时工”，只认当前标签页。你想想填表单的场景：在A标签页填了一半的注册信息，还没提交就不小心关了标签页，再重新打开同一个网站（新标签页），刚才填的内容全没了——这就是sessionStorage的锅，它只在你打开的那个标签页里“干活”，标签页一关，数据就跟着“下班”了。不过这也有好处，比如你用同一个网站开两个标签页，一个登录账号A，一个登录账号B，sessionStorage里存的用户信息就不会串，因为每个标签页的sessionStorage是独立的，互不打扰。
本地存储方案的容量限制分别是多少？
不同方案的容量差异较大：Cookie 单个文件最大约4KB，适合存储少量标识信息；localStorage 和 sessionStorage 容量通常为5MB，适合中等数据量的键值对存储；IndexedDB 容量无明确上限（取决于设备硬盘空间），适合存储大量结构化数据，比如离线文档、历史记录等。
localStorage和sessionStorage的核心区别是什么？
主要差异在生命周期和作用域：localStorage 是持久化存储，数据会一直保留（除非手动删除或清理浏览器数据），且同一域名下所有标签页共享；sessionStorage 仅在当前会话有效，关闭标签页后数据自动清除，且不同标签页间数据不共享。简单说，需要“记住”的用localStorage，临时存的用sessionStorage。
哪些本地存储方案适合存敏感数据？为什么？
敏感数据（如token、用户密码）优先用Cookie，并开启安全配置：设置HttpOnly属性防止JS读取（防XSS攻击），Secure属性限制HTTPS传输，SameSite属性防止CSRF攻击。不 用localStorage/sessionStorage存敏感数据，因为它们可被页面脚本直接访问，若页面存在XSS漏洞，数据易被窃取。IndexedDB虽容量大，但同样存在脚本访问风险，敏感数据需加密后存储。
IndexedDB和localStorage相比，优势在哪里？
IndexedDB的优势体现在三个方面：一是容量更大（无上限 vs 5MB），适合存大量数据；二是支持结构化存储和复杂查询，可直接存储对象、数组，还能建索引快速搜索；三是异步操作，不会阻塞主线程，读写大量数据时页面更流畅。比如离线应用、本地日志系统、需要缓存几百条商品数据的场景，IndexedDB比localStorage更高效。
浏览器隐私模式会影响本地存储功能吗？
会有影响，不同浏览器表现不同：Cookie 在隐私模式下通常可使用，但部分浏览器会限制持久化（关闭窗口后删除）；localStorage 和 sessionStorage 在多数浏览器隐私模式下可用，但数据仅存于内存，关闭窗口后丢失，且部分浏览器可能限制容量；IndexedDB 在部分浏览器（如旧版Safari）隐私模式下可能被禁用或功能受限。开发时 加兼容处理，比如用try-catch捕获存储失败，给用户提示“当前模式不支持本地存储”。
