IndexedDB大数据存储核心是按需分片、带索引建模与生命周期管理；预加载分数据库预热与分片加载，缓存按场景建仓、索引检索、主动过期，性能兜底需容量监控与降级。
IndexedDB 存储大数据集时，预加载与缓存策略的核心不是“一股脑全存”，而是按需分片、带索引建模、配合生命周期管理。它解决的不是“能不能存”，而是“怎么存得快、查得准、不拖慢页面”。
预加载：分阶段、带优先级地打开数据通道
直接在页面初始化时加载 10 万条商品或 50 个 GLB 场景模型，会阻塞渲染。正确做法是把“预加载”拆解为数据库准备 + 数据就绪两步：
-
数据库结构预热：首次访问即调用
indexedDB.open(dbName, version)，并在onupgradeneeded中声明对象仓库和索引（如按category或updatedAt建索引），避免后续查询时临时建索引卡顿 -
数据分片加载：不一次性写入全部数据。例如电商后台可按分类分批写入，每批 ≤ 500 条，用
transaction.objectStore().add()批量提交，并监听onsuccess控制节奏 -
关键数据先行：用户最可能点击的前 20 条列表项、首页必需的 3 个模型文件，优先放入 IndexedDB 并标记
priority: 'high'，其余延后异步填充
缓存策略：按用途建仓 + 按时效清理
不同数据类型不该混存在一个对象仓库里。合理划分能提升查询效率，也便于独立管理生命周期：
-
按场景建对象仓库：比如
'products'（商品）、'glb-assets'（3D 模型）、'chat-messages'（聊天记录）各自独立，避免跨类型事务冲突 -
索引驱动快速检索：在
products仓中为name、price、status分别建索引；搜索“手机”时用index.getAllKeys('手机')获取主键，再批量读取，比遍历全量快一个数量级 -
主动过期机制：不依赖浏览器自动清理。为每条记录添加
createdAt和expiresAt字段，在写入时计算过期时间（如 30 天），定期运行清理任务：objectStore.index('expiresAt').openCursor(IDBKeyRange.upperBound(Date.now()))
性能兜底：降级与容错设计
IndexedDB 是强大但非万能——它可能被用户禁用、空间不足、或版本迁移失败。策略必须包含 fallback 路径：
-
容量监控 + 自动降级：调用
navigator.storage.estimate()获取当前可用配额，若剩余 - 读取失败回退：查询 IndexedDB 返回空时，不直接报错，而是触发一次轻量级 API 请求获取最小必要数据（如仅拉取当前页 20 条），并同步写入缓存
-
版本迁移安全锁：升级数据库结构时，
onupgradeneeded中先检查旧字段是否存在，再新增索引或迁移数据；迁移完成前禁止写入新数据，防止结构不一致
真正高效的缓存，不是堆数据，而是让数据在需要时刚好准备好、查起来刚好够快、不用时安静退出。IndexedDB 提供了这个能力的底层支撑，策略才是让它落地的关键。
