浏览器原生通过autocomplete属性记住表单内容，需用标准name/type值如email、tel；非标准数据用localstorage持久化，注意dom就绪后读取、类型转换及错误处理。
怎么让 HTML 表单记住上次填的内容
浏览器原生就支持，靠 autocomplete 属性就能实现，不用 JS 也能记邮箱、姓名、地址这些常见字段。关键不是“能不能”，而是“浏览器认不认你写的 name 或 type”。
常见错误是随便写 name="userEmail" 或 name="my-phone"，结果浏览器直接无视——它只认标准值，比如 name="email"、name="tel"、name="shipping address"（注意空格和大小写不敏感，但连字符会破坏匹配）。
-
autocomplete值必须是规范关键词，比如"email"、"given-name"、"family-name"、"street-address"、"postal-code" - 表单要有
<form></form>标签包裹，且不能加autocomplete="off"（哪怕写在 form 上也会禁掉所有子字段） - input 类型要合理：用
type="email"配autocomplete="email"，比用type="text"更可靠 - Chrome 和 Safari 对
autocomplete的支持更积极；Firefox 会略保守，尤其对自定义字段
用户改了配置后怎么持久化到本地
如果想存用户自己调过的字段顺序、默认选中项、开关状态这类非标准表单数据，就得用 JS + localStorage。别碰 sessionStorage，关个标签页就丢，用户会觉得“刚设好怎么没了”。
典型场景：一个带“是否启用通知”开关和“默认分类下拉”的配置表单，用户切换后希望下次打开还是原来的选择。
立即学习“前端免费学习笔记（深入）”；
- 监听
change或input事件，而不是只等提交时才存 - 用有意义的 key 存，比如
localStorage.setItem("form-config:notification-toggle", "true")，别用"config1"这种 - 读取时加 try/catch，
localStorage可能被禁用或满额，直接报错会卡住初始化 - 避免存整个表单 DOM 或函数，只存原始值（字符串、布尔、数字），JSON 序列化也行，但别嵌套太深
为什么 localStorage 里存的值没生效
最常踩的坑是「读早了」：JS 脚本在 input 渲染完之前就执行了读取逻辑，拿到的是 null 或旧值，然后把空值写回 input 的 value 或 checked，反而覆盖了用户上次的选择。
另一个隐形问题是类型错乱：localStorage 只存字符串，"false" 是真值，Boolean("false") === true，直接赋给 checkbox 会导致“关着的开关变开着”。
- 确保 DOM 已就绪再读取，用
DOMContentLoaded或把 script 放在 body 底部 - 还原布尔值时显式判断：
el.checked = localStorage.getItem("x") === "true" - 还原 select 时，先设
value再触发change事件（如果依赖其他联动逻辑） - 别在多个 tab 同时操作同一 key，localStorage 不触发跨 tab 事件，容易互相覆盖
要不要用 IndexedDB 存表单配置
普通用户配置，不用。IndexedDB 是为大量结构化数据设计的，比如缓存几百条表单模板、带附件的草稿。存几个开关和下拉选项，杀鸡用牛刀，还多出版本管理、事务、兼容性处理一堆事。
真正需要它的场景很窄：表单本身支持“保存为模板”，用户可创建/重命名/删除多个配置集，且每个配置包含嵌套字段或富文本。
- Chrome/Firefox/Safari 都支持，但 iOS Safari 对低版本 IndexedDB API 有 bug（比如
getAll()不返回） - 没有 localStorage 那种简单 key-value 的直觉，必须建 objectStore、开 transaction、处理 success/error 回调
- 如果只是替代 localStorage，用
localForage这类封装库更省事，但它仍掩盖不了 IndexedDB 的本质复杂度
多数情况，localStorage 加一层健壮的读写封装，已经够用。真遇到容量瓶颈（比如 >5MB），再考虑升级也不迟。
