跨表单提交时草稿不丢失的关键是主动保存每步字段值：统一用data-field-id标识字段，存取基于该属性；跳过file、disabled及非提交元素；localStorage存JSON化有效数据，服务端需draft_id+时间戳防覆盖。
跨表单提交时草稿数据怎么不丢
用户在多步骤表单（比如注册页分 3 步、订单填写分地址/支付/确认）中跳转或刷新后，已填内容直接清空——这不是浏览器问题，是默认行为。关键在于：不能依赖 form 自带的提交机制来保存中间状态，得主动把每一步的字段值抽出来，单独存到本地或服务端。
常见错误是试图用 submit 事件拦截后调 event.preventDefault()，再手动发请求，但没处理好异步失败、重复触发、字段名动态生成等情况，结果草稿存了一半就断了。
- 所有步骤表单共用同一组字段名（如
user_name、phone），避免存的时候 key 对不上 - 每步离开前（比如点击“下一步”按钮）触发一次保存，不是等最后提交才存
- 优先用
localStorage做兜底，但注意它同步阻塞、不支持跨域、大小限制约 5MB；敏感字段别存明文 - 如果表单含文件输入（
<input type="file">），它的值无法被 JS 读取路径，只能存文件名或上传后的 URL，别试图序列化File对象
localStorage 存草稿的正确写法
直接 JSON.stringify() 整个 form.elements 是错的——它包含大量 DOM 属性、方法、disabled 元素、button 等无效字段，序列化会报错或存一堆垃圾。
应该遍历并筛选出有值的可提交字段：
立即学习“前端免费学习笔记（深入）”；
function saveDraft(form) {
const data = {};
Array.from(form.elements).forEach(el => {
if (!el.name || el.name.trim() === '') return;
if (['checkbox', 'radio'].includes(el.type) && !el.checked) return;
if (el.type === 'file') return; // 跳过文件，另行处理
data[el.name] = el.value;
});
localStorage.setItem('draft_form_v2', JSON.stringify(data));
}
注意点：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
-
el.value对于select[multiple]只返回第一个选中项，要用Array.from(el.selectedOptions).map(o => o.value) - 日期控件（
type="date"）的value是字符串格式（如"2024-05-20"），无需额外格式化 - 不要用
sessionStorage替代，它在页面关闭后即失效，不满足“稍后回来继续填”的需求
自动恢复草稿时字段对不上怎么办
最常遇到的是：存的时候字段叫 addr_line1，恢复时 DOM 已经重渲染（比如 React/Vue 组件更新），新节点没有 name 属性，或用了 data-name、id 当标识符，导致 document.querySelector('[name="addr_line1"]') 查不到。
解决思路不是强行匹配 name，而是统一用「字段标识符」做桥梁：
- 给每个可编辑字段加
data-field-id（如data-field-id="shipping_phone"），存和取都基于这个属性 - 恢复时先读
localStorage，再遍历所有带data-field-id的元素，用el.dataset.fieldId匹配键名 - 如果字段是受控组件（React 的
value+onChange），不能直接改el.value，得触发对应 state 更新，否则视图不同步 - 时间类字段（
datetime-local）恢复时要检查值格式是否合法，非法值设为空字符串，否则浏览器会清空输入框
服务端存草稿要注意并发覆盖
用户可能同时在两个标签页打开同一表单，A 标签页存了第 1 步，B 标签页存了第 2 步，但 B 的请求先到服务器，A 后到——结果第 1 步的修改被覆盖。这不是前端能完全规避的问题，得靠服务端加版本控制或时间戳校验。
前端能做的最小干预：
- 每次保存草稿时带上当前时间戳（
Date.now()），服务端只接受比已有时间更新的数据 - 给每个表单实例分配唯一
draft_id（比如 UUID），首次进入时生成并存在localStorage和 URL 参数里，后续所有请求都带它 - 避免用用户 ID 作为草稿主键——一个用户可能同时填多个同类表单（比如两个未完成的订单）
- 服务端草稿记录建议加 TTL（比如 7 天自动清理），不然数据库里全是僵尸数据
真正难的不是存和取，是字段映射关系一旦松动（比如后端改了字段名、前端重构了组件结构），草稿就变成不可读的 JSON 字符串。所以草稿键名必须稳定，且最好有简单 schema 记录（哪怕只是注释）。
