前端存储

一、为什么需要本地存储的“三重保险”机制 你是否经历过这样的崩溃时刻？ 正在编辑一篇 3000 字的技术长文，光标还在第 17 段，浏览器突然卡死 → 强制刷新 → 所有未提交内容灰飞烟灭。 或者误点了「清空表单」按钮，再点「撤销」时发现——前端根本没有实现撤销逻辑。 更隐蔽的是：localStorage.setItem('draft', JSON.stringify(data)) 这行看似稳妥的代码，实则埋着三颗雷： 数据丢失：用户关闭标签页前未手动保存，beforeunload 未监听或失效； 覆盖无痕：每次 setItem 都直接覆盖旧值，上一版内容永久消失，毫无痕迹； 无法回退：没有时间戳、没有版本标识，连「5 分钟前的内容长什么样」都无从考证。 这正是单一 localStorage 写入模式的根本缺陷：它只提供「最终状态存储」，而非「变更过程管理」。 而「三重保险」机制，正是为填补这一空白而生： ✅ 自动保存（Auto-save）解决实时性问题：在用户输入间隙静默落盘，不打断创作流； ✅ 版本快照（Snapshot）解决可追溯性问题：每份快照自带时间戳、哈希与上下文，支持按需回溯； ✅ 一键恢复（Restore）解决容错性问题：用户主动触发时，可预览、确认、精准还原，且自动保护当前未保存变更。 最关键的是：整个流程 100% 前端自治。无需后端 API、不依赖网络、不增加服务器负载——特别适合笔记类 PWA、离线文档编辑器、表单草稿箱等场景。 二、基础环境准备与工具选型 本方案兼容所有现代浏览器（Chrome 80+ / Firefox 78+ / Safari 14+），对旧版可通过轻量级兜底保障可用性： 组件 推荐方案 理由 localStorage 兼容性 使用 localforage 或自建 tryStorage() 封装 Safari 无痕模式下直接抛 SecurityError，需降级至内存缓存 内容压缩 lz-string（仅 3KB gzip） 长文本快照易突破 localStorage 5MB 限额，压缩率常达 60–75% 时间处理 dayjs（2KB） 替代 moment.js，轻量且支持相对时间格式化（如 "2 分钟前"） ❌ 为何不用 IndexedDB？ 它虽容量大、支持事务，但 API 复杂（需打开 DB、创建 ObjectStore、处理 versionchange）、错误边界多，对「草稿快照」这类简单场景属于过度设计。 ...