HTML5浏览器存储有配额限制，需主动检测与降级：localStorage/sessionStorage约5–10MB，IndexedDB可达50–250MB，Cache API受同源总限制；应通过试探写入、计数预估、异常捕获及分级fallback（如内存缓存、分批重试、URL hash）保障可用性。
HTML5 的浏览器存储（如 localStorage、sessionStorage、IndexedDB）并非无限可用，不同浏览器对单个源（origin）设置了不同的配额限制，超出时会抛出异常。处理不当会导致数据丢失或功能中断，需主动检测、合理分配并优雅降级。
各存储机制的典型配额与触发条件
配额因浏览器、设备类型（桌面/移动端）、隐私模式而异，常见情况如下：
-
localStorage / sessionStorage：通常为 5–10 MB（Chrome 桌面约 10 MB，Safari iOS 约 5 MB，Firefox 约 10 MB），写入超限时抛出
QuotaExceededError； -
IndexedDB：配额更高（Chrome 可达 60% 磁盘空闲空间，但初始硬限制约 50–250 MB），在事务提交（
transaction.commit()）或批量写入时可能失败，错误类型为AbortError或QuotaExceededError； - Cache API（Service Worker）：无明确文档配额，但实际受同源总存储限制约束，大量缓存易触发整体配额耗尽。
运行时配额检测与预判策略
浏览器未提供标准 API 直接读取剩余配额，但可通过试探性写入+异常捕获间接估算：
- 对 localStorage，可先尝试写入一段已知长度字符串（如 1MB），捕获
QuotaExceededError判断是否濒临满载； - IndexedDB 可监听
upgradeneeded和blocked事件，并在打开数据库时检查event.newVersion是否为null（表示打开失败，可能因空间不足）； - 更可靠的方式是维护本地写入计数器 + 估算平均条目大小，在写入前做软性容量预检（例如：当前已存 800 条，每条均值 8 KB → 已占 ~6.4 MB，接近 10 MB 阈值则触发清理）。
溢出时的标准异常捕获与降级路径
所有存储操作必须包裹 try-catch，并按优先级提供 fallback 方案：
立即学习“前端免费学习笔记（深入）”；
- localStorage 写入失败时，可降级至内存 Map 缓存（页面生命周期内有效），并提示用户“离线数据暂未持久化”；
- IndexedDB 批量写入失败，应拆分为小批次重试（如每次 50 条），同时自动触发旧数据清理（按时间戳删除 >7 天的记录）；
- 若所有持久化方式均不可用（如隐身模式下 Safari 完全禁用 localStorage），应将关键状态序列化后附在 URL hash 或通过
document.hidden+ 页面卸载前保存到 sessionStorage（部分浏览器仍允许）。
长期可用性增强建议
避免被动等待溢出，从设计层面缓解压力：
- 敏感/临时数据优先用 sessionStorage，退出标签页即释放；
- 大文件（图片、音频）不直接存 Base64，改用 Blob URL + URL.createObjectURL()，或上传至服务端后仅存 ID；
- 为 IndexedDB 设置 TTL 字段，配合后台定时任务（如使用
navigator.idleDeadline或requestIdleCallback）清理过期数据； - 在 DevTools Application 面板中定期查看 “Storage” 占用详情，对第三方 SDK（如分析脚本）的本地写入行为做审计。
不复杂但容易忽略：配额不是固定值，它随浏览器版本和用户设置动态变化。把存储当作有成本的资源来管理，比事后救火更有效。
