核心是统一入口、适配行为、分层容错：需兜底indexeddb全局对象，兼容onupgradeneeded与setversion版本升级逻辑，按浏览器差异调整事务超时与用户交互要求，并配置调试验证与localstorage降级兜底。
处理 IndexedDB 在不同浏览器下的差异，核心是统一入口、适配行为、分层容错。不能指望一套代码在 Chrome、Firefox、Safari 上“开箱即用”，必须主动应对版本机制、事务限制、隐私策略等关键分歧。
统一 indexedDB 全局对象入口
各浏览器对全局 API 的命名不一致，需手动兜底：
- Chrome/Edge（Blink）：用
window.indexedDB - Firefox（Gecko）：早期用
window.mozIndexedDB，新版本已兼容标准名 - Safari（WebKit）：旧版强制要求
window.webkitIndexedDB，iOS 16+ 已支持标准名，但部分 macOS 版本仍需前缀
推荐写法（简洁可靠，覆盖主流场景）：
const indexedDB = window.indexedDB || window.webkitIndexedDB || window.mozIndexedDB || window.msIndexedDB;
同理，也建议对 IDBKeyRange 和 IDBTransaction 做类似兼容处理。
版本升级逻辑必须兼容新旧规范
Firefox 10+、Chrome 24+ 使用 onupgradeneeded 事件；而旧版 Safari（≤12）、老版 Chrome（≤22）依赖 setVersion()。若只写新版逻辑，低版本 Safari 会静默失败。
稳妥做法是：调用 open(dbName, version) 后，在 onsuccess 中检查 db.version 是否匹配预期。不匹配时，优先尝试 onupgradeneeded；若该事件未触发，再 fallback 到 setVersion()（仅对支持它的环境）：
- 先监听
onupgradeneeded，正常处理 schema 变更 - 在
onsuccess回调中加判断：if (db.version !== expectedVersion) { /* 触发降级兼容流程 */ } - 避免在
onsuccess里直接调用createObjectStore——这在任何版本都会报错
事务行为要按浏览器特性调整
事务不是“写了就跑”，它受浏览器硬性约束：
- Safari 事务默认超时 30 秒，且必须有用户交互触发才允许开启 readwrite 事务（如点击、触摸），否则静默拒绝
- Chrome/Edge 超时约 60 秒，相对宽松；Firefox 几乎无自动超时
- Safari 隐私模式下完全禁用 IndexedDB，Firefox 和 Chrome 则仍可用
应对策略：
- 所有写操作前，确保已在用户手势（
click、touchstart）回调内启动事务 - 对长耗时操作（如批量导入），拆分为多个小事务，每批 ≤ 50 条，避免超时
- 在初始化阶段主动检测：
try { await indexedDB.open('test', 1); } catch(e) { /* 提示离线功能受限 */ }
调试与降级兜底不能少
开发阶段靠浏览器开发者工具验证实际行为：
- Chrome/Edge：Application → IndexedDB，可实时查看结构、增删记录
- Firefox：Storage → IndexedDB，支持相同操作，但某些索引查询需事务显式完成才刷新
- 若看不到数据库，先确认
indexedDB.open()是否执行、是否被onerror拦截、是否在file://协议下运行（此时全盘失效）
生产环境建议设置降级路径：
- IndexedDB 不可用时，fallback 到 localStorage（仅限简单键值）
- 写失败时捕获
DOMException，记录错误类型（如QuotaExceededError、AbortError），并提示用户清理缓存 - 对 Safari 用户，可在首次加载时弹出轻量提示：“为保障数据保存，请允许网站存储信息”
