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是结构变更的唯一入口，但它不负责数据一致性。这两点叠加，就是大部分“升级失效”问题的根源。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
