IndexedDB多窗口版本升级需关闭所有旧连接才能触发onupgradeneeded，应监听blocked事件协调、用localStorage广播关闭信号、确保升级逻辑幂等、采用逐级升级模式并严格在versionchange事务中执行结构变更。
在多窗口环境下处理 IndexedDB 版本升级，关键在于理解 versionchange 事务的排他性机制——它要求所有已有连接必须关闭后，新版本升级才能获得锁并执行。浏览器不会自动同步各标签页的数据库状态，因此必须靠开发者主动协调。
多窗口下 onupgradeneeded 触发的前提条件
只有当某个窗口调用 indexedDB.open("mydb", newVersion)，且该 newVersion 高于当前数据库版本时，才会触发 onupgradeneeded。但此时若其他窗口仍持有旧版本的 IDBDatabase 实例（未调用 db.close()），升级事务会被挂起，直到所有旧连接释放。
- 打开新窗口调用
open("mydb", 2)，但主窗口还连着 v1 数据库 →onupgradeneeded不会立即执行，request 处于 pending 状态 - 主窗口手动执行
db.close()后，新窗口的升级事务才真正开始 - 若用户强制刷新或关闭所有旧标签页，系统会在下次 open 时自动获得升级锁
监听 blocking 事件主动协调旧连接
新版浏览器支持在 onupgradeneeded 中监听 blocked 事件，用于感知升级被阻塞，并通知用户或其他窗口主动关闭连接。
- 在
onupgradeneeded处理器中添加：db.addEventListener('blocked', () => alert('请关闭其他页面以完成升级')) - 更友好的做法是通过
localStorage广播信号：一个窗口检测到升级需求，写入localStorage.setItem('db_upgrade_pending', '2')，其他窗口监听storage事件并自动调用db.close() - 注意：
blocked只在升级被卡住时触发，不是每次 open 都有
升级逻辑必须幂等且可重入
由于多窗口场景下无法保证哪个窗口最先完成升级，onupgradeneeded 中的代码要能安全重复执行，避免建两次同名 objectStore 或索引。
- 用
db.objectStoreNames.contains("users")判断是否已存在，再决定是否调用createObjectStore - 迁移旧数据时，先读取源 store 内容，写入新结构，最后才调用
deleteObjectStore("oldStore") - 避免依赖全局变量或单次标记位，改用数据库内建状态（例如在
metastore 中记录已执行的升级步骤）
避免降级与版本跳跃陷阱
IndexedDB 不允许降级（如从 v3 调用 open("mydb", 2) 会失败），也不推荐跨多版本直接跳转（如 v1 → v3），否则容易遗漏中间版本的迁移逻辑。
- 推荐采用“逐级升级”模式：v1 → v2 → v3，每个
switch(event.oldVersion)分支只处理紧邻版本变更 - 首次安装（
event.oldVersion === 0）走完整初始化；升级则按 oldVersion 值依次补全缺失步骤 - 所有结构操作（
createObjectStore、createIndex）严格限定在onupgradeneeded的 transaction 中，不可挪到onsuccess
