表单草稿应实时存 localStorage：input 事件存文本、change 存选择类；手动遍历 elements 取值，加前缀避免冲突；加载时检查字段是否为空再恢复，防覆盖用户输入；提交成功后必须在响应成功回调中清除草稿；多标签页需用 storage 事件提示或时间戳比对，防止覆盖。
表单数据没提交前怎么存到 localStorage
页面刷新或误操作后表单内容直接清空，是前端最常被吐槽的体验之一。直接在 input、textarea、select 的 change 或 input 事件里序列化保存就行，但得注意时机和字段覆盖逻辑。
-
input事件比change更及时（实时存），适合文本类；change适合select或 checkbox 群组，避免高频触发 - 别用
form.serialize()（jQuery）或new FormData(form)直接转对象——它们不包含未选中的 checkbox 和 disabled 字段，容易漏数据 - 手动遍历
form.elements，对每个element.value或element.checked取值，按element.name当 key 存进localStorage - 记得加前缀，比如
localStorage.setItem('draft-form-contact', JSON.stringify(data))，避免和其他表单冲突
页面加载时自动恢复草稿，但不覆盖用户新输入
恢复逻辑写在 DOMContentLoaded 里没问题，但关键是怎么判断“该不该恢复”：用户刚打开页面？还是中途刷新？有没有正在编辑？
- 恢复前先检查
form.elements是否全为空——如果已有值（比如 URL 带参数预填了邮箱），跳过恢复，否则会把用户刚输的内容冲掉 - 给表单加个标记字段，比如
data-draft-restore="done"，恢复完立刻设上，防止多次执行 - 恢复后别直接
focus()第一个输入框——打断用户操作流，尤其手机端软键盘弹出很突兀 - 如果表单有动态增删字段（如多组联系人），只恢复已存在的 DOM 节点对应字段，新增项不还原，避免索引错位
submit 成功后必须清除 localStorage 草稿
这是最容易漏的一步。用户提交成功，但 localStorage 还留着旧数据，下次再进页面又恢复出来，导致重复提交或信息错乱。
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 清除动作必须放在
fetch或axios的then（且状态码为 2xx）之后，不能放submit事件里——因为提交可能失败 - 别用
localStorage.removeItem('draft-form-contact')就完事，最好加个确认：比如服务端返回{ success: true, draft_cleared: true }，再清本地 - 如果表单支持“保存为草稿”按钮（非 submit），要单独处理：点击时只存不删，且标记
data-draft-status="saved"，方便区分
多标签页同时编辑同一表单怎么办
用户开两个 tab 填同一个表单，A 页存了草稿，B 页不知道，继续改——最后 B 提交，A 的修改就丢了。这不是 bug，是设计缺陷。
立即学习“前端免费学习笔记（深入）”；
- 用
localStorage+storage事件监听：当一页存了新草稿，其他页收到事件后可提示“检测到其他窗口修改，请刷新” - 存草稿时加时间戳字段：
draft: { data: {...}, timestamp: Date.now() }，恢复前比对时间，若本地草稿比 storage 里的旧，说明已被覆盖，不恢复 - 更稳妥的做法是引入内存锁：首次聚焦表单时写入
sessionStorage标记，其他 tab 检测到该标记存在就禁用编辑并提示 - 别依赖
localStorage做协同，它没有原子性，setItem不是事务，高并发下可能丢字段
表单备份看着简单，真正上线后出问题的，八成卡在多 tab 场景或 submit 后没清缓存——这两处一漏，用户就会觉得“系统记错了”。
