草稿箱功能的核心是“内容不丢”，需通过localStorage或服务端持久化实现断网/刷新后恢复；须防抖保存、自动填充、提交后清理，并兼顾跨端同步、版本管理、安全清洗与隐私合规。
草稿箱功能的核心是“内容不丢”，关键在于把用户未提交的输入及时存到可靠的地方，而不是只留在内存或表单里。持久化存储就是让草稿在页面刷新、意外关闭甚至网络中断后依然可恢复。
选对存储方式：localStorage 是最简可行方案
对于大多数 Web 草稿箱（如编辑器、留言框、表单填写），localStorage 是起步最快、兼容性最好、无需后端支持的选择。它在同源下持久保存字符串，关掉浏览器再打开也能读取。
- 每次用户输入（建议防抖 500ms～1s）就调用
localStorage.setItem('draft-key', content) - 页面加载时优先检查 localStorage，有对应 key 就自动填充到编辑区，并提示“检测到未发送的草稿”
- 提交成功后，务必调用
localStorage.removeItem('draft-key')清理，避免旧草稿残留 - 注意：localStorage 单域名上限约 5–10MB，且只能存字符串——复杂结构需用
JSON.stringify()存，JSON.parse()取
进阶：服务端持久化 + 版本管理
当草稿需跨设备同步、多人协作或内容敏感（如长文、富文本含图片），仅靠前端存储不够。此时应把草稿发到后端暂存，并带上唯一标识（如文章 ID 或临时 draftId）和时间戳。
- 用户开始编辑时，先请求接口生成一个 draftId，后续所有保存都带上它
- 每次保存走轻量 POST 接口（如
/api/drafts/:id），后端只更新内容和 updated_at，不校验完整性 - 可增加「自动版本」机制：每 2 分钟或内容变化超 300 字，保存一个快照，方便回溯修改过程
- 前端展示“最后保存于 X 分钟前”，并提供「恢复上一版本」按钮，点击即拉取历史快照覆盖当前编辑区
体验细节决定成败
技术实现只是基础，用户是否愿意用、敢用，取决于交互是否自然、反馈是否明确。
- 保存状态要有视觉反馈：比如输入框右上角显示「已保存」小图标，3 秒后淡出；失败时显示「保存失败，已缓存至本地」并重试
- 离开页面前拦截：监听
beforeunload，若内容有变更但未提交，弹出提示“内容尚未发送，确定要离开？” - 草稿清理策略要透明：比如「7 天无操作自动删除」，在草稿列表中显示「最后编辑：2024-06-10」，让用户自主决定是否保留
- 移动端需额外考虑：微信 WebView 中 localStorage 可能被清空，建议关键场景同时写入 IndexedDB 作兜底
别忽略边界情况
真实使用中，意外比想象中多。几个容易被忽视但高频的问题：
- 同一内容多端编辑：A 在电脑写，B 在手机改，没冲突检测会覆盖。解决办法是保存时带上客户端时间戳，提交前比对服务端最新时间，不一致则提示“他人已更新，请合并后再提交”
- 富文本粘贴含样式/图片：直接存 innerHTML 容易带 XSS 风险。应清洗 HTML 或转为 Markdown 存储，渲染时再安全解析
- 表单类草稿（如注册页）：不要只存字段值，还要存当前步骤、验证状态、错误提示，否则返回时用户得重新点下一步、再输一遍验证码
- 隐私与合规：草稿若含身份证号、手机号等，localStorage 不加密即等于明文暴露。敏感字段应脱敏存储，或交由后端加密处理
