indexeddb多版本兼容设计核心是用统一api契约屏蔽浏览器差异，必须通过onupgradeneeded执行结构变更，校验oldversion防重复迁移，新增字段读写需空值合并，删除字段须游标清理，索引操作要分步兜底，多标签页需运行时检查并降级fallback。
IndexedDB 的多版本兼容设计，核心不在“适配浏览器差异”，而在于**用统一的 API 契约屏蔽底层实现差异**。浏览器对 IndexedDB 的支持已趋成熟（Chrome、Firefox、Safari、Edge 全面支持；IE10/11 仅部分支持），真正的兼容难点是版本迭代过程中如何让新旧代码共存、数据结构平滑演进，同时不因浏览器能力微差导致迁移失败。
版本升级必须走 onupgradeneeded，不能跳过或绕行
所有主流浏览器都强制要求结构变更必须通过 onupgradeneeded 触发。这不是可选流程，而是 IndexedDB 的底层契约：
- 即使只是新增一个索引，也必须升级版本号，并在该回调中显式调用
createIndex() - 不能在
onsuccess里尝试重建对象仓库——老版本浏览器（如 IE11）会直接报错或静默失败 - 务必校验
event.oldVersion，避免重复执行迁移逻辑（例如 v1 → v2 → v3 升级时，v2 的迁移代码只应执行一次）
字段增删要兼顾读写两端，尤其注意 IE 和 Safari 的宽容性差异
不同浏览器对缺失字段的容忍度基本一致（JS 对象属性访问不报错），但行为细节仍需兜底：
- 新增可选字段（如
theme）：写入时可选传，读取时一律用空值合并，如user.theme ?? 'light' - 删除字段（如
tempToken）：旧数据仍保留该字段，新逻辑应忽略；若需清理，必须在onupgradeneeded中用游标遍历并put()覆盖（IE11 不支持deleteIndex()后立即重名重建，需分步处理） - Safari 对键路径嵌套较敏感（如
'profile.avatar'），建议扁平化字段设计，避免跨浏览器解析歧义
索引操作需按浏览器能力分层处理
索引创建本身兼容性好，但删除和修改选项存在风险：
- 新增索引（
createIndex('byStatus', 'status')）在所有支持 IndexedDB 的浏览器中均可安全执行 - 删除索引前，先检查是否被代码依赖：可封装一个
safeDeleteIndex工具函数，在调用deleteIndex()前扫描源码或运行时标记 - 修改索引唯一性（如从非唯一改为
{ unique: true }）属于破坏性变更：必须先deleteIndex()，再createIndex(..., { unique: true })，并在迁移中手动去重（Safari 旧版对重复键处理更严格）
多标签页场景下，用数据库实例缓存+版本嗅探规避不一致
用户可能同时打开多个标签页，其中一些运行旧版代码、连接着低版本 DB 实例。这时不能假设 db 一定含最新索引：
- 每次打开数据库后，主动检查
db.objectStoreNames.contains('users')和store.indexNames.contains('byStatus')，缺失则提示降级或触发轻量迁移 - 避免在未确认索引存在的前提下直接调用
index.get()——IE11 会抛NotFoundError，Safari 可能静默返回undefined - 对关键查询做 fallback：比如按 status 查询失败时，退回到主对象仓库 + 游标过滤（性能差但保底可用）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
