localStorage 在普通模式下持久化存储且无需配置，但隐私模式下仅内存暂存、关闭即清空；存对象需 JSON 序列化，跨协议/跨域不可访问，应检测可用性并按 indexedDB→localStorage→sessionStorage→内存逐级降级。
localStorage 数据本身是持久的，但“持久”只在普通浏览模式下成立——它不会因页面刷新、浏览器重启甚至电脑关机而丢失；一旦进入隐私/无痕模式，数据就变成临时的，窗口关闭即清空，且不落盘、不跨窗口共享。
localStorage 的“持久”是有前提的
它默认就具备持久化能力，无需额外配置。只要满足三个条件：用户没手动清除浏览数据、没启用隐私模式、没用脚本调用 clear() 或 removeItem()，数据就会一直留在本地硬盘上。但现实中，很多“存不住”的情况其实不是 API 问题，而是环境或使用方式不对：
- 在 Chrome 无痕窗口、Firefox 隐私窗口里写入的数据，关闭窗口后自动消失
- 直接存对象（如
localStorage.setItem('user', {name: 'Alice'})）会变成[object Object]，取出来无法还原 - HTTP 页面试图读取 HTTPS 域名下存的 localStorage（跨协议隔离，读不到）
- 单页应用中反复覆盖同一个 key，逻辑上等于“覆盖旧值”，不是存储失效
隐私模式下 localStorage 实际表现
它没有被禁用，而是被临时隔离：所有读写操作都成功，但数据仅驻留在当前会话内存中，不写入磁盘。这意味着：
- 新开一个同域名的隐私窗口，
localStorage是空的，彼此完全隔离 - 刷新页面或跳转路由不影响数据，只有关闭整个隐私窗口才会清空
- 调用
setItem和getItem不会报错，也无需特殊权限检测 -
storage事件在隐私模式下通常不触发，不能依赖它做跨标签同步
如何让 localStorage 更可靠
不能假设它一定可用，尤其面向真实用户时。关键做法是主动检测 + 合理降级：
- 每次使用前先做可用性测试：尝试写入、读取、删除一个测试 key，捕获
SecurityError或QuotaExceededError - 存对象必须用
JSON.stringify()，取回必须用JSON.parse()并加try/catch——用户可能手动改过内容，导致 JSON 损坏 - 重要状态（如登录 token）不要只存 localStorage，应和服务端 session 或 Cookie 结合校验
- 当检测失败时，按
indexedDB → localStorage → sessionStorage → 内存对象（Map 或 plain object）逐级降级，避免功能中断
别指望准确判断是否处于隐私模式
目前没有标准 API 能 100% 可靠识别隐私模式。常见试探方法（如写入后立即读取比对、监听 storage 事件是否触发）在不同浏览器表现不一，Safari 17+ 甚至会静默拒绝而不报错。更务实的做法是：把隐私模式当作一种“存储不可靠环境”，默认按降级策略处理，而不是花力气去精准识别。
