无痕模式下 localstorage 不可用，应通过最小写入尝试探测并优雅降级。初始化时仅探测一次，写入读取均需 try/catch，降级优先级为内存对象 > cookie > 服务端暂存，避免将其当作数据库使用。
无痕模式下 localStorage 无法写入，直接调用 setItem 会抛出 QuotaExceededError，导致后续逻辑中断甚至页面崩溃。关键不是“绕过限制”，而是提前探测、优雅降级、避免静默失败。
先探测可用性，别依赖浏览器类型或 length 判断
无痕模式下，localStorage.length 和 localStorage.key(0) 同样会抛错，不能作为判断依据。正确做法是用一次最小写入尝试：
- 执行
try { localStorage.setItem('__test__', '1'); localStorage.removeItem('__test__'); } - 成功则说明可用；捕获到
QuotaExceededError或其他异常（如SecurityError），就认定不可用 - 这个探测应放在应用初始化阶段，且只做一次，避免重复开销
写入时必须 try/catch，且降级路径要明确
每次调用 setItem 都不能假设它一定成功。降级顺序建议按可靠性与兼容性权衡：
- 首选内存对象模拟（如
const fallbackStore = {}），适合临时状态、刷新即丢的场景 - 次选 Cookie（需注意大小限制约 4KB，且随请求发送，影响性能）
- 最后考虑回传服务端暂存（适用于登录态、关键用户行为等强一致性需求）
读取也要防御性处理，避免 JSON.parse 崩溃
即使写入成功，读取时仍可能遇到空值、损坏字符串或非法 JSON：
- 永远用
JSON.parse(localStorage.getItem(key) || 'null')并包裹try/catch - 不要直接解构或访问属性，先检查返回值是否为有效对象
- 例如：
const data = JSON.parse(localStorage.getItem('cart') || '{}'); if (typeof data === 'object' && data !== null) { /* 安全使用 */ }
别把 localStorage 当数据库用，尤其在无痕场景
无痕模式本意就是隔离和临时化，强行“持久化”违背设计初衷。如果业务强依赖本地缓存：
- 优先评估是否真需要跨页面保留——很多场景用
sessionStorage或 URL 参数更合适 - 结构化数据、模糊搜索、大量写入等需求，应改用 IndexedDB（它在多数无痕模式下仍可用，且支持事务和索引）
- 对无痕用户可温和提示：“为保护隐私，部分功能将临时保存在本页中”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
