HTML怎么做IndexedDB版本升级_HTML IndexedDB版本迁移方法最全

IndexedDB版本升级需严格递增版本号，onupgradeneeded是唯一可建删索引的位置；版本不变则不触发升级，旧标签页会阻塞升级；跨版本迁移应使用oldVersion < 新版本判断而非等于。

IndexedDB 版本升级不是“改个数字就生效”，它是一套有严格时序和权限限制的结构变更机制。版本号不变，onupgradeneeded 永远不会触发；版本号升了，但旧标签页还开着，升级也会被阻塞静默失败。

为什么 createIndex() 没执行，却报 “Index not found”

根本原因：你调用了 indexedDB.open("mydb", 1)，而数据库早已以 v1 存在——此时浏览器直接走 onsuccess，跳过 onupgradeneeded，索引压根没建。

• 每次新增/删改索引、对象存储（objectStore），都必须递增版本号，比如从 1 改成 2，不能复用旧值
• onupgradeneeded 是唯一能安全调用 createIndex() 或 deleteIndex() 的地方，放错位置（比如写在 onsuccess 里）会直接抛 InvalidStateError
• 即使只是加一个字段索引，也得升版本；不升，store.index("xxx") 就是 undefined

多个版本迭代时，如何避免 oldVersion 判断出错

硬编码 if (oldVersion === 1) 很危险：如果用户跳过了 v2 直接打开 v3，这段逻辑就被跳过了。正确做法是用小于比较，支持跨版本迁移。

• 用 if (oldVersion 而不是 <code>if (oldVersion === 1)，确保 v0→v2、v1→v2 都能执行 v2 的升级逻辑
• 每个版本的升级块应独立、幂等：先检查对象存储是否存在，再操作索引；创建索引前用 store.indexNames.contains("name") 避免重复建导致 ConstraintError
• 删除索引前务必确认存在：if (store.indexNames.contains("old_index")) store.deleteIndex("old_index")，否则抛 NotFoundError

旧标签页卡住升级：onversionchange 必须监听

就算你把版本号改成 3，只要另一个标签页还连着 v2 的 mydb，新页面的 onupgradeneeded 就不会触发，且无错误提示——这是最隐蔽的坑。

立即学习“前端免费学习笔记（深入）”；

• 在 onsuccess 回调里立刻给 db 绑定 onversionchange：一旦检测到版本冲突，主动 db.close()
• 配合 UI 提示（如 alert("请刷新页面") 或 modal），避免用户继续操作陈旧连接
• 不要依赖 setTimeout 等待旧标签关闭——它不可控；升级逻辑必须假设“旧连接随时可能还在”

大数据量迁移时，别在 onupgradeneeded 里遍历全量数据

在升级事务中用游标读写数万条记录，会阻塞主线程、触发浏览器警告甚至终止事务。IndexedDB 不允许你在 onupgradeneeded 中做耗时同步操作。

• 结构升级（建 store、建 index）和数据迁移要拆开：前者放 onupgradeneeded，后者放后续普通事务中渐进执行
• 可设计一个 migrationState 标记（如存到 meta store），升级后检查是否完成迁移，未完成则分批处理
• 避免在升级事务中调用 getAll() 或无范围限制的游标；count() 在无索引大表上也是全表扫描，慎用

版本号是 IndexedDB 升级的唯一开关，但它不解决并发连接问题；onupgradeneeded 是结构变更的唯一入口，但它不负责数据一致性。这两点叠加，就是大部分“升级失效”问题的根源。