localStorage 不可靠，需结合防抖、校验、event.preventDefault() 和 Service Worker 实现安全离线提交；IndexedDB 更适合复杂表单，因其支持事务、查询与文件处理。
不能只靠 localStorage 做离线提交，它连“暂存”都算不上可靠——同步阻塞、无事务、不跨域、无容量预警、无法监听失败。真要落地，必须搭配防抖、校验、event.preventDefault() 和 Service Worker 同步调度。
为什么 localStorage.setItem() 会悄悄丢数据
localStorage 是同步 API，写入大对象（比如含富文本、文件描述字段的表单）时直接卡主线程；更致命的是它没事务保障——用户填完 5 分钟订单后断网，setItem('pendingOrder', JSON.stringify(data)) 突然抛出 QuotaExceededError，但 JS 不捕获、UI 无提示，数据就没了。
- Chrome 实际上限常为 10MB，但某些安卓 WebView 或隐私模式下可能低至 2MB，且不报错只静默失败
-
JSON.stringify()后必须配JSON.parse()，漏掉任一环节会得到"undefined"字符串或null，后续赋值直接崩 - 没做可用性探测就调用：
try { localStorage.getItem('test') } catch(e) { /* 降级用 sessionStorage */ }必须加
submit 事件里怎么安全暂存而不刷新页面
最常被跳过的一步：不调 event.preventDefault()，浏览器就会走原生 form.submit() 流程——页面刷新、JS 中断、fetch 被强行终止。哪怕你写了 async/await，也完全没机会执行。
- 监听
form.addEventListener('submit', (e) => { e.preventDefault(); ... })，这是所有逻辑的前提 - 用
new FormData(form)取值，再转成对象：Object.fromEntries(formData)，别直接formData.get()—— 它对多选、文件等支持不一致 - 存前加唯一 key：
form.dataset.formKey（如"checkout-2026-q2"），避免多个表单互相覆盖 - 防抖 400ms：用户停顿后再保存，不是每敲一个字就
setItem；同时对比上次值，跳过未变字段，减少无效 I/O
网络恢复后怎么真正同步，而不是靠 navigator.onLine
window.navigator.onLine 只反映系统是否连了 Wi-Fi/网线，不表示能通服务器。真实同步时机只能靠 fetch 失败兜底 + Service Worker 主动调度。
立即学习“前端免费学习笔记（深入）”；
- 页面注册 background sync：
navigator.serviceWorker.ready.then(sw => sw.sync.register('submit-pending')) - Service Worker 中监听
sync事件，从localStorage读出待提交数据，逐条fetch('/api/order', { method: 'POST', body: JSON.stringify(data) }) - 成功后调用
localStorage.removeItem('pendingOrder')；失败则保留，并加retry: 2字段，避免无限重试压垮服务端 - 同步前先检查
localStorage是否还能访问（隐私模式下可能被禁），不可信就降级到sessionStorage或 IndexedDB
为什么复杂表单该换 IndexedDB，而不是硬撑 localStorage
当表单含 <input type="file">、时间戳排序重发、或待同步记录超过 5 条时，localStorage 就暴露本质缺陷：它不支持事务、不支持查询、遍历排序全靠 JS 内存操作。
-
File对象不能直接JSON.stringify()—— 会变成空对象；得提取name/size/type，用URL.createObjectURL(file)存临时 URL - 每条记录必须带
id: crypto.randomUUID()和status: 'pending' | 'sent' | 'failed'，避免重复提交或丢失失败记录 - 数据库必须提前初始化（页面加载时），不能等到
submit事件里才调indexedDB.open()—— 异步打开来不及存就跳转了 - 如果只是想标记“有未提交数据”，反而推荐用
localStorage存个开关，原始数据全走 IndexedDB —— 这才是合理分工
真正难的不是“怎么存”，而是“怎么确认它没丢、没乱序、没重复、没卡死”。防抖、校验、preventDefault、Service Worker 注册、IndexedDB 初始化时机——少一个，用户填的 5 分钟就白费。
