在普通浏览模式下，localStorage 会执行本地持久化存储，通常不需要任何额外设置。不过，在隐私模式或无痕模式下，它往往只会把数据临时保存在内存中，一旦浏览器窗口关闭，相关数据就会立即被清除。还需要注意，保存对象或数组时必须先进行 JSON 序列化处理。此外，localStorage 天生不支持跨协议访问，也不能跨域读取。为了提升前端存储方案的稳定性与兼容性，建议先检测 localStorage 是否可用，并按照 indexedDB→localStorage→sessionStorage→内存 的顺序逐级降级。
localStorage 数据本质上具备持久性，但这种“持久存储”只在普通浏览环境下才真正成立——它不会因为页面刷新、浏览器重启，甚至电脑关机而自动丢失；可一旦进入隐私模式 / 无痕模式，数据就会变成临时会话数据，关闭窗口即被清空，同时不会写入磁盘，也不会在不同隐私窗口之间共享。
localStorage 的“持久化存储”有前提条件
localStorage 默认具备持久化能力，无需开发者额外开启。只要同时满足以下几个条件：用户没有手动清理浏览器缓存或站点数据、当前不是隐私浏览模式、脚本中也没有调用 clear() 或 removeItem() 删除内容，那么数据通常会一直保存在本地磁盘中。不过在实际开发里，很多所谓“localStorage 失效”或“数据存不住”的情况，往往并不是 API 本身的问题，而是运行环境或使用方式出现了偏差：
- 在 Chrome 无痕窗口、Firefox 隐私窗口中写入的数据，关闭窗口后会自动删除
- 直接保存对象（例如
localStorage.setItem('user', {name: 'Alice'})）最终会被转成[object Object]，读取后无法正确还原原始结构 - HTTP 页面尝试读取 HTTPS 域名下保存的 localStorage 数据时，由于跨协议隔离，通常无法访问
- 在单页应用（SPA）中不断覆盖同一个 key，从逻辑上看属于“新值覆盖旧值”，并不是本地存储无效
隐私模式下 localStorage 的真实表现
在大多数浏览器里，隐私模式并不会彻底禁用 localStorage，而是对其进行临时隔离：读写操作依然可以正常执行，但数据只存在于当前会话的内存中，不会真正写入本地磁盘。这意味着：
- 重新打开一个相同域名的隐私窗口时，
localStorage往往是空的，窗口之间相互独立、完全隔离 - 刷新页面或进行前端路由跳转通常不会影响已写入的数据，只有关闭整个隐私窗口后才会清空
- 调用
setItem与getItem一般不会直接报错，也不一定需要特殊权限判断 storage事件在隐私浏览环境下通常不稳定，很多情况下不会触发，因此不适合依赖它做跨标签页同步
如何让 localStorage 使用更稳定、更可靠
在前端开发中，不能默认假设 localStorage 一定始终可用，尤其是在面对真实用户设备、浏览器差异和隐私设置时更是如此。更稳妥的做法是：主动检测可用性，并设计合理的降级策略：
- 每次使用前先做可用性检测：尝试写入、读取、删除一个测试 key，同时捕获
SecurityError或QuotaExceededError等异常 - 保存对象时必须使用
JSON.stringify()，读取时则使用JSON.parse()，并配合try/catch处理异常——因为用户可能手动修改过 localStorage 内容，导致 JSON 格式损坏 - 关键业务状态（例如登录 token、用户身份信息）不要只依赖 localStorage 保存，最好结合服务端 session 或 Cookie 一起校验
- 当检测到 localStorage 不可用时，应按照
indexedDB → localStorage → sessionStorage → 内存对象（Map 或 plain object）的顺序逐层降级，尽量避免页面功能中断
不要试图精确判断用户是否处于隐私模式
目前并没有统一的标准 API 能够 100% 准确识别浏览器是否处于隐私模式。常见的探测方法，比如写入后立即读取比对，或者监听 storage 事件是否触发，在不同浏览器、不同版本中的表现差异很大；例如 Safari 17+ 甚至可能在不抛出异常的情况下静默拒绝部分行为。相比之下，更实用、也更符合兼容性思路的做法是：把隐私模式视为一种“存储能力不可靠”的运行环境，默认按降级策略处理，而不是花费大量精力去做并不可靠的精准识别。
