浏览器存储需按场景选择：localStorage存小数据且持久，sessionStorage限当前标签页，cookies随请求发送且有大小限制，IndexedDB适合结构化大数据。
浏览器存储不是“选一个用就行”，而是得看场景——localStorage 适合持久存小数据，sessionStorage 仅限当前会话，cookies 要发请求且有大小限制，而 IndexedDB 才是真正能存结构化大数据的方案。
怎么安全地读写 localStorage？
localStorage 是最常用但也最容易出错的 API。它只接受字符串，直接塞对象会变成 [object Object]；而且没有过期机制，存多了还可能触发 QuotaExceededError。
- 写入前必须
JSON.stringify()，读取后必须JSON.parse()，别跳这步 - 操作前加
try...catch，尤其在隐私模式下，localStorage.setItem可能直接抛SecurityError - 检查容量：可以先
localStorage.length看键数量，再粗略估算总大小（单个域名通常上限 5–10MB，但实际受浏览器和设备影响） - 示例：
try { localStorage.setItem('user', JSON.stringify({ id: 123, name: 'Alice' })); } catch (e) { console.error('localStorage 写入失败:', e); }
sessionStorage 和 localStorage 有什么关键区别？
两者 API 完全一致，但生命周期和作用域不同——这不是“要不要持久化”的选择题，而是“用户关不关标签页”决定的。
-
sessionStorage数据只在当前 tab 有效，关闭 tab 即清空；新开 tab 或刷新页面都保留 -
localStorage同源下所有 tab 共享，且重启浏览器也不丢 - 注意：iframe 中的
sessionStorage是独立的，即使同源也不会继承父页面的值 - 别用
sessionStorage存敏感临时 token——它比localStorage并不更安全，只是“活得短”
什么时候非得用 IndexedDB 而不是 localStorage？
当你需要存超过 100KB 的数据、要支持模糊搜索、或需要事务一致性时，localStorage 就该让位了。它不是“高级版 localStorage”，而是完全不同的异步数据库模型。
立即学习“Java免费学习笔记（深入）”；
-
localStorage是同步阻塞的，大量读写会卡主线程；IndexedDB是异步的，但 API 繁琐 - 必须先
indexedDB.open()建库，升级 schema 要监听onupgradeneeded，不能跳过版本号递增 - 写操作必须在事务中进行：
transaction.objectStore('users').add(...)，且事务在事件循环结束时自动关闭 - 不支持直接索引数组字段，想按 tags 搜索得建多级 keyPath 或用
createIndex()
cookie 操作为什么现在不推荐直接用 document.cookie？
document.cookie 是个反直觉的字符串接口：读是拼接所有 cookie，写是覆盖单条，没提供删除方法，也没有默认 HttpOnly 或 Secure 控制。
- 设置 cookie 必须手动拼字符串：
document.cookie = "token=abc; expires=Fri, 31 Dec 9999 23:59:59 GMT; path=/; secure; SameSite=Lax" - 删 cookie 是靠设过期时间过去，且
path和domain必须完全匹配原设置，否则删不掉 - 现代项目应优先用服务端
Set-Cookie响应头控制，前端只用fetch的credentials: 'include'配合即可 - 若真要在前端操作，建议封装工具函数处理
encodeURIComponent、expires计算和 domain 匹配逻辑
真正麻烦的从来不是“怎么存”，而是“什么时候该删”和“多个 tab 怎么同步”。比如用户登出时，localStorage 清理不干净会导致新用户看到旧缓存；IndexedDB 的版本升级失败会让整个库不可用——这些边界情况，文档里往往一笔带过。
