当 IndexedDB 数据库版本正确但缺失对象存储（objectStore）时，无法在 onsuccess 中直接创建结构；唯一可靠方案是临时迁移数据：读取全部数据 → 删除旧库 → 以相同版本重建带完整 schema 的库 → 写回数据。
当 indexeddb 数据库版本正确但缺失对象存储（objectstore）时，无法在 `onsuccess` 中直接创建结构；唯一可靠方案是临时迁移数据：读取全部数据 → 删除旧库 → 以相同版本重建带完整 schema 的库 → 写回数据。
IndexedDB 的设计严格遵循版本化 Schema 约束：所有结构变更（如创建 objectStore 或 index）必须发生在 onupgradeneeded 事件中，且仅当打开数据库时指定的版本号高于当前版本时才会触发该事件。因此，即使用户数据库版本为 v5 且应包含某 objectStore，若实际缺失，你无法在 onsuccess 回调中补建——浏览器会抛出 InvalidStateError，因为此时事务处于只读模式，且 upgrade 流程已结束。
直接升级到 v6 并非稳健解法：一方面可能引入新 bug 影响更多用户；另一方面，若 v6 升级逻辑本身存在缺陷（如未兼容旧数据格式），反而会扩大故障面。更本质的问题在于：Schema 损坏属于数据层异常，不应依赖“递增版本号”来兜底，而需主动校验与修复。
✅ 推荐方案：同版本重建（Version-Preserving Reconstruction）
核心思路是在保持数据库版本号不变（仍为 v5）的前提下，通过“重建”恢复完整 Schema。具体步骤如下：
- 打开当前库，读取全部数据（使用 readonly 事务遍历所有 objectStore）；
- 关闭并删除旧库（indexedDB.deleteDatabase(dbName)）；
- 以相同版本号重新打开，在 onupgradeneeded 中定义完整 Schema；
- 写入迁移后的数据（使用 readwrite 事务批量插入）。
async function repairIDB(dbName, dbVersion, storesConfig) {
// Step 1: Read all data
const data = {};
const openReq = indexedDB.open(dbName, dbVersion);
return new Promise((resolve, reject) => {
openReq.onsuccess = async (e) => {
const db = e.target.result;
const tx = db.transaction(db.objectStoreNames, 'readonly');
try {
for (const storeName of db.objectStoreNames) {
const store = tx.objectStore(storeName);
data[storeName] = await new Promise(resolveStore => {
const req = store.getAll();
req.onsuccess = () => resolveStore(req.result);
req.onerror = () => resolveStore([]);
});
}
db.close();
// Step 2: Delete corrupted DB
const delReq = indexedDB.deleteDatabase(dbName);
delReq.onsuccess = () => {
// Step 3 & 4: Reopen with same version, rebuild & restore
const reopenReq = indexedDB.open(dbName, dbVersion);
reopenReq.onupgradeneeded = (e) => {
const db = e.target.result;
for (const { name, keyPath, indexes } of storesConfig) {
if (!db.objectStoreNames.contains(name)) {
const store = db.createObjectStore(name, { keyPath });
for (const { name: idxName, keyPath: idxKeyPath } of indexes || []) {
store.createIndex(idxName, idxKeyPath);
}
}
}
};
reopenReq.onsuccess = async (e) => {
const db = e.target.result;
const tx = db.transaction(storesConfig.map(s => s.name), 'readwrite');
try {
for (const { name } of storesConfig) {
const store = tx.objectStore(name);
if (data[name]?.length) {
for (const item of data[name]) {
store.add(item);
}
}
}
await new Promise(r => tx.oncomplete = r);
resolve({ repaired: true, restored: Object.keys(data).length });
} catch (err) {
reject(err);
}
};
reopenReq.onerror = reject;
};
delReq.onerror = reject;
} catch (err) {
reject(err);
}
};
openReq.onerror = reject;
});
}
// 使用示例：修复 v5 数据库，确保包含 'sessions' 和 'cache' store
repairIDB('myAppDB', 5, [
{ name: 'sessions', keyPath: 'id', indexes: [{ name: 'expiry_idx', keyPath: 'exp' }] },
{ name: 'cache', keyPath: 'url' }
]).then(result => console.log('修复完成:', result))
.catch(err => console.error('修复失败:', err));
⚠️ 注意事项：
- 内存限制：该方法要求全部数据可载入内存，适用于中小型数据库（建议
- 原子性与错误处理：务必在 deleteDatabase 前确保读取成功，并在重建阶段捕获写入异常，避免数据丢失；
- 用户感知：修复过程需 UI 提示（如“正在修复本地数据…”），并禁用相关功能直至完成；
- 预防优于修复：在应用启动时增加 Schema 校验逻辑（如检查 objectStoreNames 是否完备），首次发现缺失即触发修复，而非等待用户报告。
综上，IndexedDB 无“热修复”机制，但通过受控的同版本重建，可在不改变语义版本、不引入新风险的前提下，彻底解决 objectStore 缺失问题——这是目前最稳妥、可落地的生产级修复策略。
