Websql已被W3C正式弃用，主因是依赖sqlite导致跨浏览器不一致、SQL字符串拼接缺乏安全机制、与标准化的IndexedDB路线冲突；chrome和firefox已弃用或未支持，仅safari webview默认启用；替代方案需按场景分层选择：简单数据用localStorage，结构化数据用IndexedDB，需SQL能力可用sql.js，强离线同步则需CRDT等后端协同方案。
WebSQL 已被正式弃用，且没有被任何标准替代——它不是“暂时不推荐”，而是从规范到浏览器支持都已停止演进。
WebSQL 为什么被弃用
W3C 在 2010 年将 WebSQL 规范移交至“废弃状态”（Abandoned），核心原因有三点：
- 底层依赖 SQLite，导致跨浏览器行为不一致（例如 Chrome 和 Safari 实现细节不同，Opera 曾完全不支持）
- API 基于 SQL 字符串拼接，缺乏类型安全与防注入机制，与现代前端工程实践脱节
- 与 IndexedDB 这一基于对象存储、可扩展、标准化的方案形成路线冲突，W3C 选择全力推进后者
Chrome / Safari / Firefox 对 WebSQL 的实际支持现状
支持 ≠ 推荐，更不等于可持续使用：
-
Chrome：仍保留window.openDatabase，但控制台会输出[Deprecation] WebSQL is deprecated警告；未来版本可能移除 -
Safari（ios/macOS）：是目前唯一“默认启用且无警告”的浏览器，但仅限于 UIWebView/WKWebView 内部（即 Hybrid app 场景），Safari 浏览器本身也已标记为废弃 -
Firefox：从未实现 WebSQL，调用window.openDatabase直接返回undefined
替代方案不是“选一个”，而是按场景分层
没有“一个新 API 完全对标 WebSQL”，需根据数据规模、查询复杂度、离线需求来组合使用：
立即学习“前端免费学习笔记（深入）”；
- 简单键值对（用户偏好、开关状态）→
localStorage或sessionStorage（注意：仅支持字符串，需json.stringify/JSON.parse） - 结构化、中等规模（百条以上记录，需索引/事务）→
IndexedDB（用idb库封装可大幅降低使用门槛） - 需要 SQL 查询能力（如已有 SQL 逻辑迁移、报表类场景）→
sql.js（在内存中运行 SQLite 编译版，支持select、JOIN，但数据不持久化，需自行同步到 IndexedDB） - 强离线 + 多端同步 → 不再靠前端单点数据库，改用
CRDT或Operational Transformation方案 + 后端协调（如Automerge+ 自建 sync endpoint）
const dbPromise = idb.openDB('my-app-db', 1, { upgrade(db) { const store = db.createObjectStore('users', { keyPath: 'id' }); store.createIndex('by-email', 'email'); } }); // 插入 dbPromise.then(db => db.add('users', { id: 1, name: 'Alice', email: 'a@b.com' })); // 查询索引 dbPromise.then(db => db.transaction('users').objectStore('users') .index('by-email').get('a@b.com'));真正容易被忽略的是：WebSQL 的“可用”具有极强的上下文依赖性——它在 iOS WebView 里能跑，在 PWA 中却大概率失效；它的 SQL 看似熟悉，但无法用参数化防止注入，也无法做跨表外键约束。与其花时间绕过弃用警告，不如把迁移成本算进排期里。