表单草稿应实时存 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 还留着旧数据，下次再进页面又恢复出来，导致重复提交或信息错乱。
云点滴客户关系管理CRM OA系统
下载
云点滴客户解决方案是针对中小企业量身制定的具有简单易用、功能强大、永久免费使用、终身升级维护的智能化客户解决方案。依托功能强大、安全稳定的阿里云平 台，性价比高、扩展性好、安全性高、稳定性好。高内聚低耦合的模块化设计，使得每个模块最大限度的满足需求，相关模块的组合能满足用户的一系列要求。简单 易用的云备份使得用户随时随地简单、安全、可靠的备份客户信息。功能强大的报表统计使得用户大数据分析变的简单，
- 清除动作必须放在
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 后没清缓存——这两处一漏，用户就会觉得“系统记错了”。
