旧版浏览器 IndexedDB 升级易静默失败，需适配行为边界：检测 indexedDB 别名、低版本试探、检查 store 存在性、索引名小写+下划线、加防抖、事务轻量、游标前校验 active、分片迁移、监听 versionchange 并强制关闭。
旧版本浏览器（尤其是 Safari 10.3–12.1、iOS 11.3 以下）在 IndexedDB 版本升级时容易出现“静默失败”或“升级卡住”，这不是传统死锁，而是因规范差异、事件触发不稳、事务中止不可控导致的升级逻辑中断。解决核心不是绕过限制，而是适配其行为边界。
兼容性降级：统一获取 indexedDB 实例
旧版 Safari 不支持标准 window.indexedDB，可能只暴露 window.webkitIndexedDB；Firefox 旧版还残留 mozIndexedDB。直接调用会报 undefined 或 InvalidStateError。
- 按顺序检测并挂载标准接口：
webkitIndexedDB → mozIndexedDB → indexedDB - 同时映射
IDBKeyRange和IDBTransaction别名，避免后续方法调用失败 - 首次打开不确定版本时，先用低版本（如
1）试探，再根据db.version判断是否需重开高版本
规避 onupgradeneeded 不触发
旧版 Safari 对 onupgradeneeded 触发极为严格：版本号未递增、多次快速 open、或 store 已存在但未预判，都会导致事件跳过，索引建不上、结构改不了。
- 升级前必须检查
db.objectStoreNames.contains('storeName')，避免重复createObjectStore()静默失败 - 索引名强制小写+下划线（如
"created_at"），避开 iOS 11.2 及以下对大小写/特殊字符的解析异常 - 加 50–100ms 防抖逻辑，防止同一页面短时间内多次
open()导致事件丢失
事务安全：防自动中止与游标失效
旧版 WebKit 中，事务超过约 50ms 就会被浏览器强制 abort，且不触发 onabort；游标继续 continue() 会抛 TransactionInactiveError，看似卡死。
立即学习“Java免费学习笔记（深入）”；
- 所有 upgrade 事务内操作要轻量——索引创建可做，但避免遍历数万条数据
- 游标迭代中每次
cursor.continue()前，检查transaction.active === true，否则中止并提示用户刷新 - 涉及数据迁移（如补字段），拆成小批次（如每次 100 条），用
setTimeout或requestIdleCallback分片执行
主动兜底：监听 versionchange + 强制关闭
即使你升了版本号，只要另一个标签页还连着旧版数据库，onupgradeneeded 就不会触发——旧版 Safari 更倾向静默阻塞而非报错。
- 在
onsuccess回调里立刻绑定db.onversionchange = () => { db.close(); alert("请刷新页面以应用更新"); } - 不要等写入时报错才处理，这是预防性动作
- 可在页面初始化时比对
window.db?.version与当前代码期望版本，不一致即引导刷新
