先说几个核心判断：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 本身。
