草稿保存优先用localstorage，因其简单同步、api直观、5mb容量足够单表单场景；indexeddb对仅需按id存取json的草稿属于过度设计，但需注意json序列化限制、高频写入抖动（应防抖）、时间戳校验、冲突提示及发布后精准清理。

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

草稿保存用 localStorage 还是 IndexedDB？ localStorage 足够应付大多数表单草稿场景，它简单、同步、API 直观，而且所有现代浏览器都支持。IndexedDB 虽然容量大、支持事务和复杂查询，但对“用户填一半关掉页面再回来”这种需求属于过度设计——你不需要查“上周三未提交的 200 字描述含‘紧急’的草稿”，只需要按表单 ID 存取一个 JSON 对象。

• localStorage.setItem('draft-form-123', JSON.stringify(data)) 是最直接的写法，但要注意 JSON.stringify 无法序列化函数、undefined、Date 对象（会变成字符串）、RegExp 等；表单里若有自定义组件状态，得提前清洗
• 别在每次 input 事件里立刻写入 localStorage——高频触发会导致性能抖动，尤其在移动端；用 debounce 控制在 800ms 内无输入再保存更稳妥
• localStorage 有约 5MB 限制，但单个表单草稿极少超 100KB；真正要警惕的是同域下多个应用共用导致 quota 耗尽，建议加前缀如 'myapp-draft-form-'

怎么监听表单变化并提取有效数据？ 不要遍历所有 input、textarea、select 手动取值——容易漏掉动态插入的字段、disabled 元素、富文本编辑器内容。推荐用事件委托 + 表单级序列化逻辑：

• 给表单加 data-draft-id="post-create" 属性，作为草稿 key 的来源
• 监听 form 元素的 input 和 change 事件（change 覆盖 checkbox/radio 的点击，input 覆盖实时输入）
• 提取数据时优先用 new FormData(form)，它自动处理文件、多选、name 属性；但注意它不包含 disabled 字段，也不支持富文本区域（contenteditable 需单独读 innerHTML 或 innerText）
• 若表单含 quill 或 tiptap 编辑器，必须监听其特定事件（如 quill.on('text-change')），不能依赖原生表单事件

页面加载时如何安全恢复草稿？ 恢复不是“有就塞进去”，而是要防冲突、防覆盖、防过期。核心是比对时间戳和用户意图：

• 草稿数据里必须存 savedAt 时间戳（Date.now()），加载时检查是否超过 7 天，过期则自动丢弃——避免用户半年后打开旧页面，误恢复早已作废的草稿
• 恢复前先判断当前 URL 或表单状态是否匹配：比如草稿是为 /admin/post/edit/456 存的，而用户打开的是 /admin/post/create，就不能自动填充
• 不要静默覆盖用户当前输入；显示提示条：“检测到未提交的草稿，是否恢复？”并提供“恢复”“清除并新建”两个按钮，用 confirm() 太粗暴，体验差
• 恢复后需重置草稿时间戳，否则下次保存会沿用旧时间，导致“刚恢复的草稿又被判定为过期”

发布成功后怎么清理草稿？ 提交成功响应返回 201 或 200 后，清理动作必须与业务逻辑解耦，且确保只清对应草稿：

• 别在 fetch().then() 里直接 localStorage.removeItem()——网络请求成功不代表后端事务最终一致（比如发邮件失败回滚），应等后端明确返回“已持久化且不可逆”才清理
• 推荐在成功回调中调用统一清理函数：clearDraft('post-create')，该函数内部检查 key 是否存在、是否匹配当前表单 ID，再移除
• 如果表单支持“另存为草稿”和“正式发布”两种按钮，注意“另存为”不应清空草稿，而“发布”必须清空；两者按钮的 type 和事件处理逻辑要严格区分
• 用户手动点击“清空草稿”时，应弹出二次确认，尤其当草稿非空且修改时间距今

草稿机制真正的难点不在存储，而在“什么时候不该恢复”和“什么时候不该清除”。时间戳、表单上下文、用户显式操作意图，这三者缺一不可。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！