IndexedDB 应用于解决大数据量、快速查询、离线可用及不阻塞页面等前端具体问题；需按职责拆分对象存储、合理设计主键与索引、分离大体积数据，并在版本升级时保障兼容性。
选 IndexedDB 不是为“用上新技术”，而是解决具体问题：数据量大、要查得快、得离线可用、不能卡页面。它不是后端数据库的简化版，而是浏览器环境里专为前端交互优化的数据层。
按数据职责拆分对象存储
一个对象存储只管一类事，别堆在一起。比如学习类应用里，“单词条目”“用户答题记录”“错题本”就该分三个存储，而不是全塞进一个 words 里。
- 单词条目存基础字段（id、word、phonetic、definition），体积小、读频高
- 答题记录按 session 或日期分片，避免单条过大影响游标遍历
- 错题本单独建表，用 wordId 做外键索引，方便点击单词直接跳转错题详情
混存会导致查询慢、事务重试多、升级迁移困难——尤其是某类数据要加字段或改结构时，牵一发而动全身。
主键与索引：只建真正会查的
主键优先用业务 ID（如后端返回的 id 字段），设为 keyPath；没稳定 ID 就用 autoIncrement，别手动生成时间戳或随机数。
- 索引只加在会被 get() 以外操作用到的字段上：比如 status 用于筛选、updatedAt 用于倒序列表、userId 用于隔离用户数据
- 避免给 contentLength、wordCount 这类计算字段建索引——它们几乎不参与 WHERE 条件
- 索引名要有含义，比如 by-user-status 比 idx1 更容易维护
大体积数据必须分离存储
Blob、ArrayBuffer、长文本内容别和元数据放一起。一张图片存进对象存储，可能让整条记录变大几十倍，拖慢所有读写操作。
- 把附件、音频、缓存 HTML 片段等单独建 assets 存储，用业务 ID 当 key 或外键关联
- 主表只保留引用字段（如 assetId）和轻量元信息（类型、大小、上传时间）
- 加载时按需取附件，比如列表页只显示缩略图 URL，点开详情才 fetch 对应 Blob
版本升级要预留兼容性
IndexedDB 的 onupgradeneeded 是唯一能改结构的地方。升级不是“加个字段”那么简单，得考虑已有数据怎么过渡。
- 新增字段默认值写清楚，比如 isArchived: false，别让旧数据读出来是 undefined
- 字段重命名或类型变更，要在迁移逻辑里做转换，不能只重建 store
- 测试不同版本间的数据读写兼容性，尤其注意索引是否被误删或重复创建
不复杂但容易忽略。
