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 2024 10:23:45 GMT+0800 (CST)"
localStorage.setItem('fn', () => {}); // 存进去的是 "() => {}" 字符串，取出来不是函数，无法执行
常见踩坑场景：
立即学习“Java免费学习笔记（深入）”；
- 存时间戳比存
Date对象更安全：localStorage.setItem('ts', Date.now().toString()) - 存对象前务必检查是否可序列化——
undefined、function、Symbol、循环引用都会让JSON.stringify()报错或丢数据 - 不要依赖
localStorage存敏感信息（如 token），它不防 XSS；应配合httpOnlyCookie 做身份校验
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）推荐存在内存变量或
httpOnlyCookie 中，而不是localStorage—— 这是安全边界问题，不是存储能力问题
真正需要持久化小量元数据（如语言偏好、暗色模式开关），localStorage 更轻量；需要服务端感知的状态（如登录态），交给 Cookie + 后端 session 控制更稳妥。
