17370845950

localStorage数据永不过期且同源标签页共享，sessionStorage仅当前标签页有效、关闭即清空；二者均只支持字符串存储，存对象需JSON序列化，容量约5–10MB，不支持函数、Date等非字符串类型。

JavaScript 客户端存储不是“选一个就行”，而是得看你要存什么、存多久、有多大、是否需要跨域或同步——localStorage 和 sessionStorage 最常用，但它们不能存函数、Date、undefined 或 DOM 节点；IndexedDB 才是真正能存结构化数据的方案；而 Cookie 现在基本只用于身份凭证传递，别拿来存业务数据。

localStorage 和 sessionStorage 的核心区别在哪？

两者 API 完全一致（setItem、getItem、removeItem），但生命周期和作用域不同：

• localStorage：数据永不过期，除非手动调用 clear() 或用户清除浏览器数据；同一协议+域名+端口下所有标签页共享
• sessionStorage：仅当前标签页有效，关闭该标签页即清空；即使同域名，新开标签页也是独立的存储空间
• 都只能存字符串。存对象必须先 JSON.stringify()，取出来要 JSON.parse()；否则会静默转成 "[object Object]"
• 容量通常为 5–10 MB（各浏览器不同），但写入大体积字符串可能触发 QUOTA_EXCEEDED_ERR

为什么不能直接用 localStorage 存 Date 或函数？

因为 localStorage 底层只接受字符串值。任何非字符串类型都会被强制调用 .toString()：

localStorage.setItem('now', new Date()); // 存进去的是 "Mon Apr 01 2025 10:23:45 GMT+0800 (CST)"
localStorage.setItem('fn', () => {});       // 存进去的是 "() => {}" 字符串，取出来不是函数，无法执行

常见踩坑场景：

• 存时间戳比存 Date 对象更安全：localStorage.setItem('ts', Date.now().toString())
• 存对象前务必检查是否可序列化——undefined、function、Symbol、循环引用都会让 JSON.stringify() 报错或丢数据
• 不要依赖 localStorage 存敏感信息（如 token），它不防 XSS；应配合 httpOnly Cookie 做身份校验

IndexedDB 什么时候必须上？

当你遇到这些情况时，localStorage 就不够用了：

• 要存超过 10 MB 的数据（比如离线图片、音频片段、大量日志）
• 需要按字段查询、索引、范围遍历（比如“查今天创建的所有笔记”）
• 要支持事务、版本升级、多标签页并发读写
• 需存二进制（Blob、ArrayBuffer）或嵌套结构，且不想手动序列化/反序列化

它不是“高级 localStorage”，而是完整数据库引擎。初始化复杂，但一旦建好 objectStore，增删改查就稳定得多。注意：indexedDB.open() 是异步的，所有操作都基于 request 对象，不能像 localStorage 那样直接赋值。

Cookie 还算客户端存储吗？

算，但它设计目标从来不是“存前端数据”。现代前端几乎不该用它存业务状态：

• 每次 HTTP 请求都会自动带上（浪费带宽），最大仅 4 KB
• 需要后端设置 Set-Cookie 头才能写入；前端只能用 document.cookie 读写（且不能跨域）
• 若没设 Secure 和 HttpOnly，极易被 XSS 窃取；设了 HttpOnly 后，JS 又读不到
• 现在主流身份方案（如 JWT）推荐存在内存变量或 httpOnly Cookie 中，而不是 localStorage —— 这是安全边界问题，不是存储能力问题

真正需要持久化小量元数据（如语言偏好、暗色模式开关），localStorage 更轻量；需要服务端感知的状态（如登录态），交给 Cookie + 后端 session 控制更稳妥。