ObjectStore 参数配置需权衡读写效率、内存与索引开销：keyPath 决定主键管理方式，autoIncrement 适用于序号ID；索引数量影响写入吞吐，应仅对高频查询字段创建；openKeyCursor 适合轻量遍历，openCursor 用于全量数据操作；命名与结构变更需配合版本升级并谨慎迁移。
ObjectStore 的参数配置直接影响读写效率、内存占用和索引开销，不是“设了就行”，而是需要按使用场景权衡。
主键路径（keyPath）是否启用自增，决定插入速度和主键管理成本
设置 keyPath（如 "id"）表示数据自带主键，插入时需确保字段存在且唯一；不设 keyPath 而启用 autoIncrement: true，则由 IndexedDB 自动分配数字主键。
- 带 keyPath 插入更快——无需生成主键，但要求应用层保证主键不重复、不缺失
- autoIncrement 模式下，每次插入都要维护内部计数器，高并发写入可能轻微延迟（尤其在大量小事务中）
- 若业务主键是字符串（如 UUID），必须用 keyPath；若只是序号 ID，autoIncrement 更省心且避免冲突
索引数量与字段选择，显著影响写入吞吐和磁盘空间
每个 createIndex() 都会在写入时额外维护一份索引数据。8 个索引会让单条记录写入变成 9 次写操作（1 主 + 8 索引）。
- 只对实际用于查询的字段建索引，比如
"completed"和"createdAt"是待办系统高频筛选条件，值得建 - 避免为仅用于展示的字段（如
"description"）建索引，除非要做全文模糊匹配（此时应考虑分词+前缀索引或外部方案） - 复合索引（如
["status", "priority"]）适合组合查询，但会增大索引体积，且无法单独加速status或priority单字段查询
store.openKeyCursor 与 store.openCursor 的差异，影响遍历性能
游标遍历时，是否需要读取完整数据体，决定了 I/O 开销大小。
-
openKeyCursor只返回主键，适用于统计、校验、批量删除等无需内容的场景，速度快、内存低 -
openCursor加载整条记录，适合渲染列表或做字段计算，但大数据量下易触发内存压力 - 若只需某几个字段，可考虑在索引中覆盖所需字段（IndexedDB 不支持真正意义上的“覆盖索引”，但可通过索引 + 主键回查减少数据加载量）
对象仓库名与数据库版本联动，影响升级时的迁移成本
ObjectStore 在 onupgradeneeded 中创建，其名称、keyPath、autoIncrement 等属于结构定义。一旦上线，修改这些参数即需升级版本并手动迁移数据。
- 命名尽量语义化且稳定，如
"user_profiles"比"users_v2"更利于长期维护 - 初期不确定是否要主键，宁可先用
autoIncrement: true，后续再通过迁移脚本补全业务主键字段，比强行预留空 keyPath 更稳妥 - 删除旧 ObjectStore 前，务必确认无残留引用，否则
versionchange事务会失败并阻塞整个数据库打开流程
