SessionStorage 仅限当前标签页会话，关闭即销毁，适合表单草稿等临时状态；LocalStorage 持久化跨标签页，适合用户偏好等长期数据，但需防覆盖与安全风险。
SessionStorage 和 LocalStorage 的核心区别不在 API，而在数据生命周期和作用域——选错一个，轻则状态丢失，重则跨标签页数据污染。
什么时候该用 sessionStorage？看会话边界
它只活在“当前标签页+当前页面刷新”这个范围内。关闭标签页、关掉浏览器、甚至新开同地址的标签页，数据都不共享、不继承。
- 适合存临时状态：比如表单草稿（用户没提交就刷新了，还能恢复）、多步流程中的中间步骤（如地址→支付→确认）、播放器当前进度（仅限本窗口）
- 不能用于判断“用户是否刚进入”：因为刷新页面不会清空
sessionStorage，但关闭再打开就会清空——这点常被误判 - iframe 同源时可共享：如果页面嵌了同域
iframe，它们共用同一个sessionStorage实例，这点比很多人想的更“粘”
什么时候该用 localStorage？看持久性与跨页需求
只要域名不变，数据就一直躺在硬盘里，重启浏览器、换标签页、甚至几天后回来，都能读到。
- 适合存用户偏好：主题色、语言、折叠面板状态；也适合缓存非敏感静态资源（如离线词典、配置项）
- 注意同步问题：如果两个标签页同时写同一个 key，后写的会覆盖前写的，且无事件通知——
storage事件能监听到变化，但无法阻止竞争写入 - 别存敏感信息：它不加密、不防 XSS，token 或密码明文塞进去等于裸奔；哪怕加了 base64 也算“裸奔”
为什么不能混用？常见翻车现场
错误不是语法报错，而是行为不符合预期：
- 用
sessionStorage存登录态 → 用户开第二个标签页就登出（因为新标签页没有该 session 数据） - 用
localStorage存表单草稿 → 用户在 A 标签页填一半，切到 B 标签页继续填，结果 A 的草稿被 B 覆盖（同 key 写入） - 以为
sessionStorage能防刷新丢失 → 没问题；但以为它能防“用户手滑关掉整个浏览器” → 就会丢数据 - 在 Safari 的无痕模式下测试 →
localStorage可能直接抛QuotaExceededError，连setItem都失败，需兜底 try/catch
兼容性和容量：别信“5MB”这个数字
标称容量是假象。实际可用空间受浏览器、私有模式、磁盘配额策略影响极大：
- Chrome 正常模式约 10MB，但无痕模式可能只剩几百 KB；Safari 移动端曾长期卡在 2.5MB
- 检测是否可用不能只靠
typeof localStorage !== 'undefined'，还得 try 写入再读取验证 - 存对象必须
JSON.stringify()，读取后必须JSON.parse()；直接存null或undefined会被转成字符串"null"，容易引发类型 bug
真正难的不是记住区别，而是预判用户操作路径——他会不会开多个标签页？会不会关浏览器再回来？会不会在 iframe 里跳转？这些场景决定了该锁死作用域，还是主动共享状态。
