无痕模式下indexeddb受限，需探测降级：调用open并100ms超时判断，失败则用内存map兜底；慎用localstorage，须二次验证；业务层接受无持久现实，引导手动保存或服务端暂存。
无痕模式下 IndexedDB 不是“坏了”，而是被浏览器主动限制——它可能初始化失败、打开超时，甚至静默拒绝写入。处理的关键不是硬扛，而是快速探测、及时降级、做好兜底。
先探测，别假设
不能只靠 typeof indexedDB !== 'undefined' 判断可用性，因为无痕模式下对象存在但不可用。必须发起一次真实打开操作：
- 调用 indexedDB.open('probe-db', 1)，并设置 100ms 超时（用 Promise.race 或 setTimeout 控制）
- 监听 onerror 和 onupgradeneeded：若 error 触发，或超时后仍无响应，即判定不可用
- 成功后立即调用 db.close() 并删除测试库（indexedDB.deleteDatabase('probe-db')），避免残留
优先用内存 Map 降级
无痕模式的本意就是“不持久”，所以内存存储反而是最符合预期的选择：
- 封装一个轻量适配器，提供 get/put/delete/clear 接口，行为尽量对齐 IndexedDB
- 底层用 Map 或普通对象缓存，不依赖任何持久化机制
- 页面刷新即清空——这不需要额外处理，本身就是设计目标
慎用 localStorage 作备选
部分浏览器（如 Safari 隐私模式）会阻止 localStorage 写入，甚至抛出 SecurityError。若仍想尝试，必须二次验证：
- 执行 localStorage.setItem('test', 'x')，再立即 getItem('test') 比对值
- 捕获异常或读取为空，则彻底放弃本地持久化，只保留内存方案
- 注意：localStorage 容量小、阻塞主线程、不支持二进制和复杂对象，仅适合简单字符串配置
业务层接受“无持久”现实
前端不能强依赖客户端存储，尤其在无痕场景下：
- 关键操作（如长文本编辑、大文件上传）增加手动保存提示，引导用户复制内容
- 服务端提供草稿接口，自动将无痕用户切换到服务端暂存
- 在 UI 显著位置提示：“当前处于隐私模式，关闭窗口后数据将清除”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
