离线存储WebSQL失效后HTML文档DOM持久化替代方案

先说几个核心判断：IndexedDB 是目前唯一能够兼顾存储容量、数据结构和离线可用性的客户端数据库方案。它不遵循 SQL 那一套语法，但提供了事务、索引、游标和二进制存储能力，处理中等规模的结构化数据完全足够。初始化时必须老老实实监听 onupgradeneeded 事件创建好 objectStore，否则会直接抛出 NotFoundError 报错。

WebSQL 在离线模式下并不可靠

WebSQL 已被 W3C 正式废弃。Chrome 133 开始在非安全上下文（HTTP 环境）中直接禁用 window.openDatabase，Safari 17 起仅允许在 HTTPS 页面调用，Firefox 则从未支持过。更关键的是：即便调用成功，在无痕模式下它要么返回 undefined，要么抛出 SecurityError。离线场景中，根本无法依赖它正常工作。不要抱有“能用就行”的侥幸心理——它确实不可靠。

DOM 数据该存什么、怎么存才能真正离线可用

很多开发者直接存储 element.outerHTML，这是一个常见误区——事件监听器会丢失，绑定的 JS 对象引用会丢失，Canvas 绘图状态也会丢失，还原出来的只是一个静态快照，毫无灵魂。真正能够持久化的，是 DOM 背后的数据模型，而不是渲染出来的外观。

• 表单内容 → 存储 { name: '张三', email: 'z@x.com' } 这样的纯对象，不要碰 form.innerHTML
• 富文本编辑器 → 存储 Markdown 字符串，或者 Slate / ProseMirror 的 JSON AST，不要存储渲染后的 div 树
• 动态列表项 → 存储数组 [{ id: 'i1', title: '任务A', done: false }]，渲染时再生成 DOM
• 所有数据必须可序列化（函数、DOM 节点、Date 实例等都不行），否则 JSON.stringify() 会静默丢弃它们

IndexedDB 是当前唯一兼顾容量、结构与离线能力的客户端方案

它不是 WebSQL 的“平替”，设计哲学完全不同。虽然不支持 SQL，但提供了事务、索引、游标和二进制存储，处理 DOM 渲染所需的中等规模结构化数据完全够用。

• 初始化必须监听 onupgradeneeded 创建 objectStore，否则后续 transaction.objectStore('xxx') 会直接报 NotFoundError
• 写入操作必须在 transaction.oncomplete 之前完成，否则触发 TransactionInactiveError
• 读取结果要判空：const item = event.target.result; if (!item) return;，不要直接解构 undefined
• 小数据可以用 localStorage.setItem('dom-data', JSON.stringify(model))，简单且兼容性好；但数据超过 2MB 就可能阻塞主线程，影响首屏渲染

无痕模式下必须降级到内存缓存

几乎所有浏览器在无痕模式中都会拒绝 localStorage 写入（直接抛出 QuotaExceededError），IndexedDB 也受限制（Safari 直接失败，Firefox 使用临时实例）。这条路走不通。唯一稳妥的方案是内存缓存：

• 使用 Map 或普通对象暂存当前会话的 DOM 模型，配合路由 history.state 传递轻量状态
• 表单输入实时更新内存对象，不依赖任何持久化 API
• 页面卸载前（beforeunload）尝试写入 localStorage 或 indexedDB，失败时静默忽略
• URL 参数（data=...）只适合极简状态（例如分页页码、筛选标签），不要往里面塞嵌套对象或长文本

真正的离线韧性，并不是靠“换一个存储 API”就能解决的。关键在于将 DOM 渲染逻辑和数据生命周期彻底解耦——让渲染只依赖可重建的数据模型，而不是试图保存 DOM 本身。