IndexedDB是突破localStorage容量限制的唯一全平台可行方案，其配额基于磁盘空间动态分配，Chrome下可达140GB以上，并支持压缩、分块、清理及封装库优化。
网页大数据缓存遇到 localStorage 的 5–10 MB 硬性上限时，IndexedDB 是唯一被全平台支持、真正可行的升级路径。它不是“稍微多存一点”的替代品，而是从存储模型、容量机制到查询能力的全面重构。
为什么 IndexedDB 能突破容量限制
localStorage 的配额由浏览器内核强制限定，无法绕过；而 IndexedDB 的配额基于设备磁盘空间动态分配，主流浏览器（Chrome/Firefox/Edge）默认允许占用用户可用磁盘空间的约 50%。实测显示：普通笔记本在 Chrome 正常模式下可达 140 GB 以上，即使无痕模式也有约 1.5 GB —— 远超 localStorage 的量级。
关键点在于：
- 配额是按 origin（协议+域名+端口）整体计算，不是单个数据库或键值对独立计费
- 每个 IndexedDB 数据库独立存在，但共享同一 origin 配额池
- 可通过
navigator.storage.estimate()实时读取已用/剩余空间，避免盲目写入
如何安全高效地存放大数据
光换技术不够，结构设计和写入策略直接影响稳定性与性能。尤其当单次缓存对象超过几 MB 或总数据达百 MB 级时，需注意：
-
压缩再存：对长文本、JSON 日志等大字符串，用
TextEncoder + pako.deflate压缩，体积常减少 60–80%，显著延缓配额耗尽 -
分块处理：单条记录不要超过 16 MB（Chrome 对
IDBObjectStore.put()的隐式限制），超长内容按 1–2 MB 切片，用blobId_chunk001类键名管理 -
主动清理：定期调用
indexedDB.deleteDatabase('old-cache')删除废弃库；对长期运行的应用，可按时间戳或使用频次自动淘汰旧数据
降低使用门槛的实用方案
原生 IndexedDB API 繁琐（事务嵌套、版本升级、错误分散），不建议直接用于业务逻辑。推荐两个成熟封装方案：
-
localForage：轻量（~8 KB）、API 与 localStorage 高度兼容，适合快速迁移。支持自动 fallback 到 WebSQL/IndexDB，
setItem('key', obj)直接存对象，无需 JSON 处理 -
Dexie.js：功能完整、Promise 原生支持、链式查询友好。例如
db.users.where('city').equals('北京').toArray()一行完成条件查询，还支持复合索引、批量写入和全局错误捕获
必须避开的典型坑
很多团队踩过这些雷，导致缓存不可靠甚至页面卡死：
- 误判 localStorage 是否满：不要依赖
localStorage.length，应捕获QuotaExceededError或用 try/catch 主动探测 - 忽略同源隔离：IndexedDB 同样受 CORS 和协议限制，HTTP 页面无法读取 HTTPS 域下的库，开发环境切协议后务必清库重试
- 忽视版本升级：修改表结构（如新增索引）必须通过
onupgradeneeded，否则新字段写入会静默失败 - 在主线程做大量遍历：即便用 IndexedDB，若把全部数据
getAll()拉到内存再 filter/sort，仍会卡 UI —— 应善用游标（cursor）和索引范围查询
