web sql 已被主流浏览器弃用，不能作为降级目标；应以 indexeddb 为主、localstorage 为兜底，配合 localforage 等工具库实现自动适配与兼容。
直接说结论：web sql 已被主流浏览器弃用，不能作为降级目标；真正可行的“降级”路径是用 localstorage 做兜底，用 indexeddb 做主力，再配合工具库自动适配。所谓“转向 web sql”是个过时方案，现在只应聚焦如何让 indexeddb 更稳、更易用、更兼容。
为什么 Web SQL 不是合格的降级选项
Web SQL 底层依赖 SQLite，但自 2010 年起 W3C 就停止维护该标准。目前仅旧版 Chrome（≤56）和 Safari（有限支持）能运行，Firefox、Edge、新版 Safari 全面不支持。调用 window.openDatabase 在大多数现代浏览器中会直接报错或返回 null。强行写 Web SQL 降级逻辑，只会增加无效代码和兼容性风险，无法真正“解放存储禁锢”。
真正有效的分层存储策略
面向富文本（含 HTML 片段、样式、嵌入脚本）和图像数据（Base64 或 Blob），推荐按能力分层启用：
- 首选 IndexedDB：存原始 HTML 字符串、Blob 图像、JSON 元数据；支持事务、索引、GB 级容量；所有现代浏览器（Chrome ≥24、Firefox ≥16、Safari ≥7.1、Edge ≥12）均完整支持
- 次选 localForage：它不是降级，而是封装——自动检测浏览器能力，优先用 IndexedDB，退化时尝试 WebSQL（仅对极老 Chrome），最后 fallback 到 localStorage（并自动序列化/反序列化）
- 纯兜底 localStorage：仅用于轻量元数据（如最后编辑时间、草稿 ID 列表）；富文本内容若强制塞进 localStorage，5MB 限制在几张 Base64 图片下就会击穿，且同步操作必然导致编辑卡顿
图像与富文本协同存储的关键实践
图像不应转成 Base64 存进文本字段，而应单独以 Blob 形式存入 IndexedDB 的独立 objectStore，再用 ID 关联到富文本结构中：
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 创建两个 objectStore：
drafts（存富文本 JSON，含imageIds: ["img_1", "img_2"]）和images（存 Blob，keyPath 设为id） - 为
images创建 index：byTimestamp，便于按上传时间筛选缩略图 - 读取时用
transaction.objectStore('drafts').get(id)拿文本，再用transaction.objectStore('images').getAll(IDs)并行加载图像，不阻塞渲染
推荐工具链：少写原生 API，多用成熟封装
原生 IndexedDB 事件回调嵌套深、错误处理繁琐，实际项目中建议直接采用以下任一方案：
-
Dexie.js：支持 TypeScript、链式查询（
db.images.where('timestamp').above(Date.now()-864e5).toArray()）、自动版本迁移，适合中大型富文本编辑器 -
localForage：API 和 localStorage 几乎一致（
setItem('draft', html)），底层自动选最优引擎，适合快速迭代或兼容性要求极高的场景 - idb：仅 3KB，Promise 化原生 API，适合轻量级应用或需要精细控制事务边界的场合
不复杂但容易忽略：IndexedDB 的存储上限由浏览器动态分配，Chrome 通常给到 50% 磁盘空间（数百 MB 起步），Safari 对单个域名限制约 1GB。只要不用 Web SQL 做虚假降级，专注用好 IndexedDB + 合理分片，富文本与图像的本地存储禁锢自然解除。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
