表单刷新后数据消失是因为autocomplete="on"仅对跨页面导航有效，对F5刷新无效；浏览器表单恢复依赖name属性，且需避免JS清空value、框架干扰及beforeunload中DOM操作。
表单刷新后数据消失，autocomplete="on" 为什么没用
浏览器默认不会在页面刷新后恢复表单输入内容，哪怕你写了 autocomplete="on"。这个属性只对「跨页面导航」（比如从搜索页跳转到结果页再点返回）起作用，对 F5 刷新或地址栏回车完全无效。
真正起作用的是浏览器的「表单恢复机制」：它依赖 name 属性且仅对有 name 的控件生效；不保存 type="hidden" 或无 name 的字段；现代浏览器（Chrome 100+、Firefox 105+）还会忽略 contenteditable 区域和动态插入的表单元素。
- 确保每个
<input>、<textarea></textarea>、<select></select>都有稳定且唯一的name值（不能是随机 ID 或时间戳） - 避免在 DOM 加载后用 JS 清空
value—— 浏览器可能已缓存，但你的脚本把它抹掉了 - 如果用了框架（如 React/Vue），原生 autocomplete 失效是常态，得自己接管状态
用 sessionStorage 手动保存表单，哪些字段要监听
手动存取最可控，但容易漏掉非标准控件或状态变化。核心原则是：只监听用户可编辑、且值会变的字段，不包括只读展示、计算字段或按钮。
典型遗漏点：<textarea></textarea> 的换行符处理、<select multiple></select> 的多选数组、带格式的富文本容器（需监听 input 而非 change）、复选框/单选组的 checked 状态集合。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 绑定
input事件（不是change）—— 实时保存，避免用户还没失焦就关闭页面 - 对
name相同的复选框组，用Array.from(document.querySelectorAll('[name="agree"]')).filter(i => i.checked).map(i => i.value)提取值 - 保存前用
JSON.stringify()，恢复时用try/catch包裹JSON.parse()，防止存储损坏导致整个表单崩溃 - 别存大文件或 base64 图片，
sessionStorage容量通常只有 5–10MB，且页面关闭即清空
beforeunload 事件里恢复数据，为什么反而更糟
有人想在页面卸载前读取 sessionStorage 并填回表单，这是错的。因为 beforeunload 是同步阻塞事件，浏览器此时已停止 DOM 更新，强行操作 input 的 value 或触发 input 事件基本无效，还可能引发「页面卡死」或「白屏」。
正确时机只有一个：DOM 加载完成、表单元素可访问之后，立即执行恢复逻辑。Vue/React 用户尤其要注意 —— 必须等组件挂载（mounted / useEffect）后再读取，否则 ref 还没绑定。
- 用
DOMContentLoaded或$(document).ready()（jQuery）作为安全起点 - 不要在
beforeunload里做任何 DOM 写入，只适合发分析日志或提示「数据未提交」 - 如果用了
history.pushState导航，记得监听popstate并主动恢复，否则前进/后退时数据丢失
React 中表单恢复失败，useRef 和 useState 怎么选
用 useRef 直接操作 DOM 虽快，但绕过 React 渲染流程，会导致状态不一致：比如用户输入后组件重渲染，ref 保存的值还在，但视图被 reset 成初始值。这时候恢复逻辑看似运行了，实际没生效。
必须用 useState 配合受控组件，把表单值变成「唯一数据源」。恢复动作不是「填 DOM」，而是「设 state」，让 React 自己驱动更新。
- 初始化 state 时就读取
sessionStorage，例如：const [email, setEmail] = useState(() => localStorage.getItem('form_email') || '') - 每次
onChange同时写入sessionStorage，保证实时性 - 注意 useEffect 的依赖数组：恢复逻辑应只在首次加载时运行，加
[]，别漏掉；否则每次 state 变化都重读，造成覆盖 - 服务端渲染（SSR）场景下，
localStorage不可用，需用useEffect延迟到客户端执行
复杂表单里，多个字段的恢复顺序、异步加载时的竞态、以及用户手动清空后是否继续监听 —— 这些细节才是实际卡住人的地方。
