IndexedDB 存表单数据需先 open 数据库、onupgradeneeded 创建对象仓库、事务中 put 写入；不可存 DOM 节点，仅支持可序列化值；存 HTML 字符串须防 XSS 与体积超限。
HTML 页面怎么把表单数据存进 IndexedDB
直接存不行，得先打开数据库、建对象仓库、再用事务写入。IndexedDB 不是 localStorage 那种 key-value 简单接口，它本质是浏览器内置的异步数据库，必须走 indexedDB.open() 这套流程。
常见错误现象：页面刷新后数据消失、控制台报 InvalidStateError: Failed to execute 'put' on 'IDBObjectStore': The transaction has finished.、或者根本没触发 onsuccess 回调。
- 必须在
onupgradeneeded里创建或升级IDBObjectStore，否则后续写入会失败 - 所有读写操作必须包裹在事务（
transaction）中，且事务生命周期极短——不能跨事件循环保留 - 表单提交时别直接调
objectStore.put()，要先确保数据库已打开、事务已启动 - 推荐用 Promise 封装原生 API，避免回调地狱；但不要用 await 等整个
open()完再处理表单，那会卡 UI
示例关键片段：
const request = indexedDB.open('formDB', 1);
request.onupgradeneeded = (e) => {
const db = e.target.result;
if (!db.objectStoreNames.contains('entries')) {
db.createObjectStore('entries', { keyPath: 'id', autoIncrement: true });
}
};
request.onsuccess = (e) => {
const db = e.target.result;
const tx = db.transaction('entries', 'readwrite');
const store = tx.objectStore('entries');
store.put({ id: Date.now(), data: formData }); // formData 是你收集的值
};
为什么不能直接用 innerHTML 或 DOM 节点存进 IndexedDB
IndexedDB 只接受可序列化的 JavaScript 值（字符串、数字、数组、普通对象等），不支持 DOM 节点、函数、Window、Document 等宿主对象。试图存 document.body 或 document.querySelector('form') 会直接抛 DataCloneError。
立即学习“前端免费学习笔记（深入）”；
使用场景：想“快照”当前 HTML 结构做离线回滚？得手动提取结构信息，不是 dump 整个 DOM 树。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 存 HTML 字符串可以用
element.outerHTML，但注意它不含动态绑定的事件或状态（比如 input 的 current value） - 如果要存表单实时值，必须遍历字段取
input.value、select.value、textarea.value，而不是抓innerHTML - 复杂组件状态（如富文本编辑器内容）应优先走组件自身导出的数据格式（如 Slate 的 JSON、Quill 的 Delta），而非 HTML 片段
IndexedDB 存 HTML 字符串有啥性能和兼容性影响
纯字符串本身没问题，但体积大了会影响写入速度和内存占用。IndexedDB 单条记录建议控制在几 MB 内，超大会触发 QuotaExceededError，尤其在 iOS Safari 上更敏感。
参数差异：Safari 对 indexedDB 的实现较保守，比如不支持 deleteDatabase 的 Promise 版本，也不支持 getAll()（得用游标遍历）。
- HTML 字符串超过 1MB 时，Chrome 和 Firefox 通常还能扛，但 iOS Safari 可能静默失败或卡顿
- 别在
onsuccess里直接处理大量 HTML 字符串（比如解析、渲染），这会让事务阻塞太久，导致后续请求排队 - 如果只是缓存静态 HTML 片段，考虑配合
Cache API+ Service Worker，比 IndexedDB 更轻量
如何安全地从 IndexedDB 读出 HTML 并插入页面
读出来的是字符串，直接用 innerHTML 插入有 XSS 风险。哪怕数据是你自己存的，也要防意外注入（比如用户输入了 <script> 标签）。
容易踩的坑：用 insertAdjacentHTML 或 innerHTML 不加过滤，结果某次表单提交带了恶意脚本，下次加载就执行了。
- 如果 HTML 来源可信且结构固定（比如只含
p、span），可用DOMParser解析后白名单过滤节点类型 - 更简单做法：用
textContent渲染纯文本，或用createTextNode()+appendChild()构建安全 DOM - 若必须渲染 HTML，优先用框架自带的 sanitizer（如 React 的
dangerouslySetInnerHTML配合 DOMPurify）
一句话收尾：IndexedDB 存 HTML 不难，难的是边界清晰——什么时候该存结构、什么时候该存状态、什么时候根本不该存 HTML。真正卡住人的，从来不是 API 调用，而是数据职责的模糊地带。
