HTML5小游戏存档丢失主因是浏览器存储配额限制与自动清理机制：localStorage在设备存储紧张或长期未访问时会被静默清空，IndexedDB同样受站点活跃度影响而被整库删除，需压缩数据并同步至服务端防范。
HTML5 小游戏存档丢失，大概率不是代码写错了，而是浏览器主动清除了 localStorage 或 IndexedDB 数据——这背后是存储配额限制和自动清理机制在起作用，而非“崩溃”或“bug”。
为什么 localStorage 突然变空了？
Chrome、Edge 和新版 Safari 对单个站点的 localStorage 实际配额并不固定，它会动态压缩：当设备存储紧张、或用户长时间未访问该站点时，浏览器可能直接丢弃整个 localStorage（不警告、不提示）。Firefox 相对保守，但启用“自动清理历史记录”后也会连带清除。
- 典型触发场景：
localStorage占用超过 8–10MB，且页面近 7 天未被打开 - 隐身模式下写入的
localStorage在关闭窗口后立即失效 - 用户手动点击“清除浏览数据”并勾选了“Cookie 及其他网站数据”，
localStorage必被清空 -
localStorage.setItem()不抛错，但写入后读不到——说明已触发静默截断（部分浏览器会在超限时静默丢弃旧键）
IndexedDB 存档更稳？其实它也扛不住强制清理
IndexedDB 理论上配额更高（Chrome 可达硬盘的 60%），但它同样受“站点存储分级”策略约束：低活跃度站点的 IndexedDB 会被降级为“可驱逐状态”，一旦系统需要释放空间，就会整库删除。
- 验证是否被清空：在 DevTools 的
Application → Storage → IndexedDB中刷新后为空，基本可判定已被回收 - 不要依赖
indexedDB.open()的 success 回调存在即安全——它可能返回一个空数据库实例 - 关键操作前建议加校验：
transaction.objectStore('save').count().onsuccess = e => { if (e.target.result === 0) handleCorruptedSave(); }
如何判断是配额耗尽还是策略清理？
没有直接 API 能读取当前剩余配额，但可通过试探性写入 + 异常捕获来间接推断：
