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（如分析脚本）的本地写入行为做审计。

不复杂但容易忽略：配额不是固定值，它随浏览器版本和用户设置动态变化。把存储当作有成本的资源来管理，比事后救火更有效。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！