Web SQL（已废弃）¶
Web SQL Database 曾允许网页通过类似 SQLite 的接口执行 SQL。 它从未成为 Web 标准，规范工作早已停止，现代应用不应采用它。
当前状态¶
- Web SQL 是非标准、已废弃的历史 API。
- 浏览器支持不完整且持续退出，不能作为跨浏览器能力依赖。
- 新项目不应编写
openDatabase()代码。 - 维护旧系统时，应制定迁移和数据退役方案。
推荐的现代客户端数据库是 IndexedDB。它是标准化、异步、支持事务的 浏览器对象存储。若只保存少量偏好，可考虑 Web Storage。
历史接口识别¶
旧代码通常具有以下形态，仅用于审计识别：
const db = openDatabase("notes", "1.0", "Notes", 5 * 1024 * 1024);
db.transaction((tx) => {
tx.executeSql("SELECT id, title FROM notes", [], handleRows);
});
不要把这段代码用于新功能。即使当前测试浏览器仍可运行，也不代表未来、其他平台或 嵌入式 WebView 会支持。
为什么不能继续依赖¶
Web SQL 的实现与单一 SQL 方言紧密绑定，标准化无法继续推进。 历史 API 还存在同步思维、错误处理复杂、配额行为不一致和迁移困难等工程问题。
“浏览器里能执行 SQL”也不等于可以信任客户端数据库。 用户可以修改本地数据，XSS 代码可以在同源权限内读取或篡改数据，清理策略也可能删除它。
迁移到 IndexedDB¶
迁移应先盘点数据库名称、版本、表、索引、数据规模和旧浏览器覆盖范围。 然后设计 IndexedDB 的对象仓库、键路径和索引，不要机械模拟每一条 SQL。
典型对应关系如下：
| Web SQL | IndexedDB |
|---|---|
| 表 | 对象仓库 objectStore |
| 主键 | keyPath 或显式键 |
| 索引 | index |
| 事务 | transaction |
| 查询结果行 | 请求结果、游标或 getAll() |
迁移程序可在仍支持 Web SQL 的旧客户端上读取历史数据，写入 IndexedDB，完成校验后 记录迁移版本。迁移必须可重试，不能因中断而重复创建或丢失记录。
无法直接迁移的用户¶
如果目标浏览器已经不支持 Web SQL，页面就无法再通过该 API 读取旧数据。 重要数据不应只存在于非标准客户端数据库中。可根据产品情况提供旧版导出、服务端同步、 明确的数据丢失说明或人工恢复流程。
安全与数据策略¶
- 客户端数据库不能作为授权、余额、权限或完整性判断的唯一依据。
- 敏感数据需要最小化；前端加密不能保护同一页面运行时可用的密钥。
- 从旧库读取的字符串仍是不可信数据，输出时必须按上下文安全处理。
- 删除账户、退出共享设备或收到隐私请求时，应清理相关站点数据。
维护建议¶
- 阻止新增 Web SQL 调用并在代码检查中搜索
openDatabase。 - 统计仍持有旧数据的客户端和数据重要程度。
- 建立 IndexedDB 数据模型、迁移版本和完整性校验。
- 在迁移成功后停止双写，并逐步移除旧读取路径。
- 为不支持旧 API 的环境提供明确降级结果。
新离线应用还应结合 Service Worker 与 Cache API， 但缓存响应与保存业务结构化数据是不同职责，不应混为一谈。