自动保存本身不防丢失,真正防丢失需本地缓存+服务端心跳+用户可感知状态三层叠加:sessionStorage防刷新,localStorage定时带版本号同步,服务端异步保存并校验etag,界面实时显示保存状态并beforeunload兜底。
自动保存本身不会导致防丢失失效,但实现方式错位会让“已存”变成“白存”——比如防抖没触发就关页、恢复时机早于 DOM 就绪、多 tab 写入互相覆盖。核心不是禁用自动保存,而是让存、比、取、清四个环节严丝合缝。
直接在 input 事件里调用 localStorage.setItem() 是最常见也最危险的做法:中文输入法组合过程会高频触发,Safari 无痕模式下可能直接抛 QuotaExceededError,且同步写入阻塞主线程,输入延迟肉眼可感。
setTimeout + clearTimeout 手写防抖,延迟设为 300–800ms(太短压不住频次,太长赶不上关页)try { localStorage.setItem(...) } catch (e) { console.warn('localStorage write failed:', e) },尤其 iOS Safari 容量默认仅 5MB 且不报明确错误JSON.stringify({ value, timestamp: Date.now() }),否则读取时会报 Unexpected token u in JSON at position 0
<textarea></textarea> 和 contenteditable 元素要区分处理:textarea.value 可直取,contenteditable 得用 element.textContent(防 XSS),富文本需存 innerHTML 但恢复前必须白名单过滤(只留 <strong>、<ul> 等)恢复失败不是因为没存,而是读得太早、比得不对、赋得不全。最典型是脚本执行顺序和框架生命周期没对齐。
<script> 标签内同步读 localStorage.getItem(),此时 DOM 还没渲染,document.getElementById('xxx') 返回 null
DOMContentLoaded 后,或更稳妥地用 document.currentScript?.nextElementSibling 后立即执行value="default" 时,不能只比 localStorage 值是否非空,得先等字段挂载完成,再取当前 value 和缓存值做严格相等判断(===,不是 ==)input.value,得通过 dispatchEvent(new Event('input', { bubbles: true })) 触发响应式更新,否则视图不刷新同域名下 localStorage 全局共享,A tab 存了草稿,B tab 加载时直接覆盖,用户毫无感知。这不是 bug,是设计使然,必须主动隔离。
立即学习“前端免费学习笔记(深入)”;
const key = location.pathname + '_draft_' + (new URLSearchParams(location.search).get('id') || 'default')
draft-v2-20260415-102345,每次保存生成新 key,旧 key 不删但加过期标记localStorage 不适用,应切到 IndexedDB,利用事务和游标支持多写并发控制storage 事件可感知其他 tab 的变更,但注意它不触发于当前 tab 的写入,只通知外部变化;可用于提示“其他窗口已更新,请刷新”很多人试图在 beforeunload 回调里读 localStorage、算哈希、比对 DOM,结果在 Safari 直接报错,在 Chrome 卡顿,最终提示不弹、数据不存。
beforeunload 中禁止异步操作,且 localStorage.getItem() 在 Safari 无痕模式下会同步抛错,无法捕获window.__isFormDirty = false,每次防抖保存成功后设为 false,输入变动时设为 true
if (window.__isFormDirty) return undefined(返回字符串已废弃,现代浏览器只认 undefined 或不返回)beforeunload 必须滞后——等用户真实输入后再加监听,否则一进页面就绑,等于强制弹提示,体验极差最常被绕过的不是技术点,而是“恢复后是否清空 localStorage”。不清理,下次打开还会还原已提交的内容;清理太早,DOM 没挂载完就删,恢复逻辑失效。这个时机差几毫秒,整个防丢失闭环就断了。