用 localStorage 检测“已自动保存”需存带时间戳和哈希的完整对象，配合防抖、try/catch 兜底、DOMContentLoaded 后比对、内存变量记录脏状态，并统一序列化处理兼容性问题。
怎么用 localStorage 检测页面是否已自动保存
浏览器本身不提供“已自动保存”状态的原生 API，所谓提示，全靠你手动记录和比对。核心逻辑是：每次输入变化时存一次 localStorage，同时记下时间戳或哈希值；页面加载时读取并对比，就能判断内容是否“和上次保存一致”。
常见错误是只存内容、不存元信息——比如用户改完又删回原样，localStorage 里看着一样，但其实是“动过又复原”，不该算“已保存”。所以必须带校验字段。
- 推荐存一个对象：
{ value: "用户输入", timestamp: Date.now(), hash: "md5(内容)" }（简单场景用JSON.stringify+length或substring(0,100)做轻量哈希也够用） - 不要在
input事件里高频写localStorage，改用debounce（如 800ms 延迟），否则影响输入响应 -
localStorage在 Safari 无痕模式下会直接抛QuotaExceededError，得包一层try/catch
如何避免“已自动保存”提示误触发
提示错位最常发生在页面初始化阶段：脚本还没读完 localStorage，用户就点了提交，或者表单默认值和缓存值恰好相同，导致“未改动却显示已保存”。
关键不是“有没有存”，而是“当前编辑态是否和最后一次保存态一致”。所以得等 DOM 渲染完成、初始值填入、且缓存读取完毕后，再做首次比对。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用
DOMContentLoaded后再读localStorage，别在script标签里同步读 - 表单有默认值（如
value="hello"）时，不能只比 DOM 的value，要等input元素真正挂载完成再取值 - 如果用了框架（如 Vue/React），别直接操作
localStorage，应在mounted/useEffect里同步状态，否则视图和缓存不同步
为什么 beforeunload 里不能可靠判断是否需要提示
很多方案想在用户关页前检查“内容是否变更”，但 beforeunload 事件里无法安全读写 localStorage（Safari 会拒绝，Chrome 可能卡顿），更没法做异步校验。它只适合发一个简单布尔信号：“有未保存内容吗？”
真正可靠的判断必须提前做完，并把结果缓存在内存变量里，beforeunload 只读这个变量。
- 把“是否脏数据”状态存在一个全局布尔变量（如
window.__isFormDirty = false），每次输入变更时更新它 - 不要在
beforeunload回调里调用localStorage.getItem或计算哈希 - 注意：该事件返回字符串已废弃，现在只支持
return undefined或什么都不返回，浏览器自行决定是否弹原生提示
IE11 和 iOS Safari 的兼容性坑
localStorage 在 IE11 下对非字符串值会静默失败（比如存 null 或对象不报错但读出来是 "null"）；iOS Safari 则可能因页面后台休眠清空内存中的事件监听，导致“保存了但没更新提示”。
这不是功能缺失，而是行为不一致——得靠降级策略兜底。
- 存之前统一用
JSON.stringify，读之后用JSON.parse，避免类型丢失 - 对 IE11，加一层
typeof item === "string"校验，失败则 fallback 到sessionStorage或内存缓存 - iOS 上建议每 3 秒主动刷新一次提示状态（用
setInterval+visibilitychange事件配合），防止页面切到后台后状态停滞
