WebSQL已废弃，IndexedDB是唯一标准方案；需重构数据模型（关系型→对象存储）、事务逻辑（声明式作用域+事件驱动错误处理）和异步方式；推荐渐进迁移与idb封装。

WebSQL 已被废弃，IndexedDB 是现代浏览器中唯一受标准支持的客户端数据库方案。迁移不是简单替换 API，而是要重新思考数据模型、事务逻辑和异步处理方式。

理解核心差异：从关系型到对象存储

WebSQL 基于 SQL 语法，依赖表结构、外键、JOIN 和事务隔离；IndexedDB 是 NoSQL 风格的对象存储，以 object store（类似表）为单位，靠 keyPath 或 index 查找，不支持跨 store 关联查询。

• 原 WebSQL 中的多表关联（如 users ↔ orders），需在应用层拆解：读取 orders 后再批量查 users，或冗余必要字段（如 order 中存 user_name）
• 主键定义方式不同：WebSQL 用 INTEGER PRIMARY KEY AUTOINCREMENT；IndexedDB 用 keyPath（内嵌字段）或 autoIncrement: true（生成数字键）
• 索引非默认创建：WebSQL 的 WHERE 字段常靠已有索引加速；IndexedDB 必须显式调用 createIndex()，且仅对 indexedDB.open() 升级时生效

重构事务与错误处理逻辑

WebSQL 的 transaction 是同步开启、异步执行回调；IndexedDB 的 transaction 生命周期由请求触发，自动提交，且一旦 abort 或报错即终止。

• 避免在单个事务中混合读写多个 object store：IndexedDB 事务作用域需在 open 时声明（如 db.transaction(['orders', 'users'], 'readwrite')），未声明的 store 不可访问
• 不再使用 try-catch 包裹 executeSql：IndexedDB 错误通过 request.onerror 或 transaction.onabort 捕获，且多数操作（如 add()、get()）返回 request 对象，需链式监听
• 写操作失败不会自动回滚整个事务：需主动调用 transaction.abort()，或依赖 request.error 触发默认 abort

渐进迁移策略：兼容与验证并行

不建议“一刀切”切换，尤其在存量数据较多或业务强依赖离线写入的场景。

• 双写过渡期：新数据同时写入 WebSQL（兼容旧代码）和 IndexedDB（构建新逻辑），读优先走 IndexedDB，降级 fallback 到 WebSQL
• 数据迁移脚本：首次打开新版应用时，在 IndexedDB upgrade event 中遍历 WebSQL 表，逐条导出并写入对应 object store；注意处理 key 冲突与字段映射（如 WebSQL 时间戳转 Date 对象）
• 用 feature detection 替代 UA 判断：检查 window.indexedDB 是否存在，而非判断是否为 Safari —— 因为 Safari 虽曾禁用 IndexedDB，但 iOS 14.5+ 已全面启用

工具与模式建议：降低认知负担

直接操作原生 IndexedDB 容易出错，推荐分层封装：

• 用 idb（https://www.npmjs.com/package/idb）这类轻量 Promise 封装库，避免 request 回调地狱，支持 async/await
• 将每个 object store 封装为独立 Model 类（如 OrderStore），统一管理 schema 版本、索引定义和常用方法（find、findAll、upsert）
• 对复杂查询（如分页 + 多条件过滤），先用 index 定位范围，再用 JS filter 后续字段 —— IndexedDB 本身不支持复合 where 条件，也不支持 LIMIT/OFFSET

迁移本质是把“数据库思维”转向“客户端存储思维”：少依赖服务端式一致性，多利用前端控制力做缓存策略、冲突合并与用户体验优化。不复杂但容易忽略细节。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！