隐私模式下IndexedDB被主动禁用，需先探测再降级：发起open测试并设100ms超时，失败则用内存Map；localStorage需二次验证，否则仅用内存存储，并做好服务端兜底。
在隐私模式（如 Chrome 的无痕窗口、Firefox 的隐私窗口）下，IndexedDB 通常被禁用或初始化失败，导致 indexedDB.open() 抛出异常或回调不触发。这不是 Bug，而是浏览器的主动限制。降级处理的核心思路是：**先探测可用性，再优雅回退到内存存储或 localStorage（若支持）**。
检测 IndexedDB 是否真正可用
不能只靠 typeof indexedDB !== 'undefined'，因为隐私模式下该对象存在但不可用。需发起一次实际打开操作并监听错误：
- 调用
indexedDB.open('test-db', 1) - 监听
onerror和onupgradeneeded—— 若onerror触发或长时间无响应（建议 100ms 超时），视为不可用 - 成功后立即
db.close()清理测试库，避免残留
优先降级到内存 Map（推荐）
内存存储最安全、最一致，尤其适合临时数据（如表单草稿、UI 状态）。可封装一个轻量适配器：
- 统一接口：提供
get、put、delete、clear方法，与 IndexedDB API 行为对齐 - 使用
Map或普通对象缓存数据，不依赖持久化 - 页面刷新即丢失 —— 这正是隐私模式的预期行为，无需额外处理
谨慎使用 localStorage 作为次选
部分浏览器（如 Safari 隐私模式）会阻止 localStorage 写入，甚至抛出 SecurityError。若选用，必须二次检测：
立即学习“前端免费学习笔记（深入）”；
- 尝试
localStorage.setItem('test', 'x')并立即读取验证 - 捕获异常，失败则彻底放弃持久化，仅用内存存储
- 注意
localStorage容量小（通常 5–10MB）、阻塞主线程、不支持二进制/复杂对象
业务层做好“无持久化”兜底
前端应默认接受数据可能丢失，避免强依赖客户端存储：
- 关键操作（如大文件上传、长文本编辑）增加手动保存提示，引导用户复制内容
- 服务端提供草稿保存接口，将隐私模式用户自动切到服务端暂存
- 在 UI 显著位置提示“当前处于隐私模式，关闭窗口后数据将清除”
