IndexedDB富文本草稿箱需结构化存储（含id、title、content、metadata等），封装Promise工具类DraftStore，防抖保存+beforeunload强制存，图片用Blob分离或hash引用，并提供UI反馈与localStorage降级备份。
在HTML5中实现基于IndexedDB的富文本编辑器草稿箱，核心是把用户未发布的富文本内容（含HTML结构、图片base64或文件引用、光标位置等）可靠地持久化到本地数据库，并支持增删改查、自动保存、冲突提示与恢复。关键不在“富文本编辑器怎么做”，而在“如何让草稿真正可用、不丢、不乱”。
草稿数据结构设计要兼顾可读性与扩展性
不要只存一个 rawHTML 字符串。建议用结构化对象存储，例如：
- id：自动生成的UUID，避免时间戳冲突
- title：用户输入的标题（或从首段提取的摘要）
- content：完整的编辑器输出HTML（过滤XSS后存）
- metadata：包含 lastModified、createdAt、isAutoSaved、wordCount、imageRefs（记录base64图片的hash或blobKey）
- editorState（可选）：如光标位置、选区范围、滚动偏移，便于恢复编辑状态
这样设计便于后续支持按标题搜索、按时间排序、识别重复草稿、清理过期图片等。
封装IndexedDB操作为Promise友好型工具类
原生IndexedDB回调嵌套深、API冗长。建议封装成类，例如 DraftStore：
立即学习“前端免费学习笔记（深入）”；
- 初始化时检查并创建 objectStore（drafts），设置 keyPath: 'id' 和 index: 'lastModified'
- save(draft)：自动处理新增/更新（put），支持事务失败重试
- list(sortBy = 'lastModified', limit = 20)：返回按修改时间倒序的草稿数组
- delete(id) 和 clearOld(days = 30)：配合业务清理策略
避免在编辑器每次 keystroke 都写库——改用防抖（debounce 1.5s）+ 显式“保存草稿”按钮双机制。
处理富文本中的图片等二进制资源
直接存大体积base64字符串会拖慢IndexedDB、触发QuotaExceededError。推荐两种方式：
- 方案A（轻量级）：将图片转为Blob，用 IDBObjectURL 或 createObjectURL 临时显示；真正保存时只存其 hash + base64缩略图（≤10KB），正图延迟上传或仅本地缓存
- 方案B（健壮型）：用另一个objectStore（blobs）单独存Blob，主草稿中用 blobKey 引用；删除草稿时联动清理对应Blob
务必监听 window.beforeunload，触发一次强制保存，防止用户误关页面丢失最后修改。
提供清晰的草稿箱UI与状态反馈
草稿箱不是后台仓库，而是用户可感知的功能模块：
- 编辑器顶部显示“已自动保存 · 2分钟前”，点击跳转草稿列表
- 草稿列表每项显示标题、预览片段（截取content中纯文本前80字）、修改时间、大小图标
- 恢复草稿时，还原HTML内容 + 光标定位到上次离开位置（用range API或编辑器自身restoreSelection方法）
- 检测到同名草稿或内容高度相似时，提示“发现未保存更改，是否合并？”而非静默覆盖
不复杂但容易忽略：所有 IndexedDB 操作需加错误边界（catch DB异常），降级为 localStorage 备份（仅存最简字段），确保草稿永不“彻底消失”。
