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")
• 避免依赖全局变量或单次标记位，改用数据库内建状态（例如在 meta store 中记录已执行的升级步骤）

避免降级与版本跳跃陷阱

IndexedDB 不允许降级（如从 v3 调用 open("mydb", 2) 会失败），也不推荐跨多版本直接跳转（如 v1 → v3），否则容易遗漏中间版本的迁移逻辑。

• 推荐采用“逐级升级”模式：v1 → v2 → v3，每个 switch(event.oldVersion) 分支只处理紧邻版本变更
• 首次安装（event.oldVersion === 0）走完整初始化；升级则按 oldVersion 值依次补全缺失步骤
• 所有结构操作（createObjectStore、createIndex）严格限定在 onupgradeneeded 的 transaction 中，不可挪到 onsuccess