无痕模式下sessionStorage可能因浏览器限制无法写入，需先探测可用性再降级至内存存储，并延迟初始化以避免崩溃。
在无痕模式下，sessionStorage 可能因浏览器隐私策略限制而无法写入，抛出 QuotaExceededError 或静默失败。这不是代码错误，而是浏览器主动限制——需主动检测并降级处理。
判断 sessionStorage 是否可用
不能依赖 try-catch 捕获所有情况（部分浏览器静默失败），应先做可用性探测：
- 写入一个临时键值对，立即读取验证
- 读取后及时清除，避免污染
- 若写入失败或读取为空/undefined，视为不可用
function isSessionStorageAvailable() {
const testKey = '__storage_test__';
try {
sessionStorage.setItem(testKey, 'test');
const result = sessionStorage.getItem(testKey);
sessionStorage.removeItem(testKey);
return result === 'test';
} catch (e) {
return false;
}
}
无痕模式下 fallback 到内存存储
当 sessionStorage 不可用时，优先使用内存对象模拟其生命周期（页面关闭即销毁）：
- 创建一个全局的
inMemoryStorage对象 - 封装
setItem、getItem、removeItem、clear方法，行为与原生一致 - 注意：不支持跨 iframe 或多 tab 共享，但符合无痕场景预期
避免初始化阶段就触发写入异常
很多框架或 SDK 在启动时直接调用 sessionStorage.setItem，容易崩溃。建议：
立即学习“Java免费学习笔记（深入）”；
- 延迟初始化：等页面加载完成、用户交互后（如点击按钮）再首次写入
- 懒写入：只在真正需要持久化状态时才尝试写入
- 统一入口：所有 storage 操作走封装层，集中控制降级逻辑
兼容性提示与用户感知
无痕模式本身禁止持久化，任何 client-side storage 都可能受限：
-
localStorage同样不可用，不要切换 fallback 目标 - 服务端 session 仍有效，关键状态应由后端维护
- 可向用户轻量提示：“当前为隐私浏览，部分功能状态不跨页面保留”
