localStorage在移动端Web游戏中不具备绝对高可用性，受限于5MB上限、无配额提示、私密模式禁用、同步阻塞等问题；应以IndexedDB为主存档机制，辅以分级缓存与云存档兜底。
localstorage 在移动端 web 游戏中并不具备“绝对高可用性”，尤其在频繁存档、读盘场景下。它的设计初衷是轻量、同步、简单键值存储，而非可靠持久化方案。5mb 的硬性上限、无配额提示、跨浏览器行为不一致、私密模式下被禁用、页面刷新时阻塞主线程等问题，都会直接导致存档失败或数据丢失。真正可行的路径不是强求 localstorage 高可用，而是绕过它——用更健壮的机制承接核心存档逻辑，再辅以合理预算规划降低风险。
明确 localStorage 的真实边界与风险点
移动端浏览器对 localStorage 的限制比桌面端更严格：
- iOS Safari 在无痕模式下完全禁用 localStorage，且普通模式下实际可用空间常低于 5MB（部分机型仅 2–3MB）；
- Android Chrome 对单个 origin 的配额采用动态算法，长期未访问或存储大量小键值后可能触发静默清理；
- 写入操作是同步阻塞的，存档频率高时（如每秒一次）极易造成 UI 卡顿甚至页面无响应；
- 没有容量查询 API，无法预判是否即将写满，只能靠 try-catch 捕获 QUOTA_EXCEEDED_ERR，但此时已失败。
用 IndexedDB 替代 localStorage 承担主存档职责
Godot Web 平台默认使用 IndexedDB 存储资源和部分运行时数据，它才是移动端 Web 游戏存档的合理基座：
- 容量远大于 localStorage（通常为设备空闲空间的 50%，iOS 可达数十 MB）；
- 异步非阻塞，适合高频写入；
- 支持结构化数据、事务、版本迁移，便于做增量更新与冲突处理；
- Godot 的 platform/web/js/libs/library_godot_os.js 已封装基础 IDB 操作，可复用其初始化与错误兜底逻辑。
建议将玩家进度、关卡状态、成就等关键数据全部存入 IndexedDB，仅把极小量元信息（如最后存档时间戳、当前存档 ID）缓存在 localStorage 作快速索引。
实施分级缓存 + 容量预算策略
不追求“全量本地存档”，而是按数据价值与更新频次分层管理：
- 热数据（高频读写）：最近 3 次自动存档 → 存于 IndexedDB，启用 LRU 清理策略，总量硬限 8MB；
- 温数据（低频读、中频写）：手动存档 + 里程碑存档（如通关、解锁新角色）→ 同样存于 IndexedDB，但压缩为 LZ4 或 msgpack 格式，单文件 ≤ 1.5MB；
- 冷数据（只读、极少写）：游戏设置、UI 偏好、本地成就统计 → 可放入 localStorage，总量预算严格控制在 800KB 内，并定期校验 key 数量与总长度；
- 所有存档文件名附加哈希前缀，避免长路径名浪费空间；删除旧存档前先检查磁盘剩余配额，留出至少 2MB 缓冲。
强制绑定云存档作为最终保障
本地存储再优化也难抗系统清理、用户清缓存、换机等场景。必须将云存档作为不可绕过的基础设施：
- 接入 TapTap 云存档（免费，单存档 ≤10MB）、Google Play 游戏存档或自建轻量后端；
- 每次成功写入本地 IndexedDB 后，异步触发一次云上传（带版本号与时间戳），失败时不阻断本地流程，但记录日志并延迟重试（指数退避）；
- 启动时优先尝试拉取云端最新存档，若成功则覆盖本地；若失败，再回退到本地最新有效存档；
- 对《淘淘旧货铺》类模拟经营游戏，可将“店铺库存”“顾客好感度”等易变数据设为云专属字段，本地仅存快照，大幅降低本地体积压力。
