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标记（如存到metastore），升级后检查是否完成迁移，未完成则分批处理 - 避免在升级事务中调用
getAll()或无范围限制的游标；count()在无索引大表上也是全表扫描，慎用
版本号是 IndexedDB 升级的唯一开关，但它不解决并发连接问题；onupgradeneeded 是结构变更的唯一入口，但它不负责数据一致性。这两点叠加，就是大部分“升级失效”问题的根源。
