web storage配额非固定，需主动探测与分级降级：localstorage/sessionstorage约5–10mb，超限抛quotaexceedederror；indexeddb初始50–250mb，事务失败报aborterror或quotaexceedederror；cache api属同源总配额。检测靠试探写入、事件监听与软估算；异常捕获后依次fallback至内存缓存、分批重试、url hash等。
Web Storage 的配额不是固定值，而是动态受限的资源，必须主动探测、预估并分级应对，不能依赖默认行为或事后补救。
配额范围与触发异常类型
不同存储机制的硬性限制差异明显，且受浏览器、设备、隐私模式影响：
-
localStorage / sessionStorage：通常 5–10 MB（Safari iOS 约 5 MB，Chrome 桌面约 10 MB），超限抛出
QuotaExceededError； -
IndexedDB：初始硬限制约 50–250 MB，实际可占空闲磁盘 60%，事务提交失败时可能报
AbortError或QuotaExceededError； - Cache API：无明文配额，但属于同源总存储的一部分，大量缓存会间接挤占 localStorage 或 IndexedDB 空间。
运行时配额检测方法
浏览器未提供标准 API 获取剩余空间，需结合试探写入、事件监听与软性估算：
- 对 localStorage，可尝试写入 1 MB 占位字符串，捕获异常判断是否临近满载；
- 打开 IndexedDB 时检查
upgradeneeded或blocked事件，event.newVersion === null可能表示因空间不足无法初始化； - 维护本地计数器 + 平均条目大小估算（如已存 800 条 × 8 KB ≈ 6.4 MB），在写入前做容量预检，提前触发清理逻辑。
异常捕获与降级路径设计
所有写入操作必须包裹 try-catch，并按优先级提供 fallback：
- localStorage 写入失败 → 降级至内存
Map缓存，保留页面生命周期内可用，并提示用户“离线数据暂未持久化”； - IndexedDB 批量写入失败 → 拆分为小批次（如每次 50 条）重试，同时自动删除过期数据（如 >7 天的日志）；
- 全链路不可用（如 Safari 无痕模式）→ 将关键状态序列化后存入 URL hash，或利用
beforeunload事件尝试写入 sessionStorage（部分浏览器仍允许）。
长期可用性增强实践
单纯依赖配额上限易导致突发中断，需叠加策略提升鲁棒性：
- 敏感数据（如 token）不直存 localStorage，改用加密 + 短时效校验，或拆分至 sessionStorage（临时 access_token）+ 加密 localStorage（refresh_token）；
- 大体积缓存（如离线资源清单）绕过 Web Storage，改用 IndexedDB，避免同步阻塞与容量瓶颈；
- 启动时检测 localStorage 可用性：不仅判断属性是否存在，还需执行写入/读取/删除闭环测试，排除 Safari 隐私模式下“存在但不可用”的陷阱。
