IndexedDB索引动态维护指南：版本升级中的关键操作解析
HTML5 IndexedDB作为现代浏览器强大的本地数据库解决方案，其对象存储索引的管理遵循严格的生命周期规则。一个核心原则是：所有索引的创建与删除操作，都必须在数据库版本升级事件中集中完成，无法在运行时动态执行。理解这一机制对于构建健壮的离线Web应用至关重要。
具体而言，开发者只能在onupgradeneeded事件触发时，通过对应的IDBObjectStore对象调用createIndex()或deleteIndex()方法。这一设计确保了数据库结构变更的原子性和一致性，但同时也对升级流程的顺序控制、错误处理和向后兼容提出了更高要求。
索引新增策略：在版本升级中安全创建索引
为IndexedDB对象存储新增索引，首要前提是确认其基础存储结构已就位。若对象存储尚未创建，需优先调用createObjectStore()；若已存在，则可直接在其上操作。需特别注意索引名的唯一性约束——重复创建同名索引将触发"ConstraintError"异常。
- 预检查机制：建议在执行创建前，通过
objectStore.indexNames.contains('indexName')进行存在性校验，有效避免运行时冲突。 - 参数配置匹配业务逻辑：
unique（唯一性约束）与multiEntry（数组多入口索引）等选项需根据数据特性谨慎选择。例如，为用户ID或邮箱字段建立索引时，通常需启用{ unique: true }以保证标识唯一。 - 标准创建示例：典型操作如
store.createIndex('emailIndex', 'email', { unique: true })，清晰定义了索引名称、键路径及约束条件。
索引删除规范：仅支持升级事务内操作
需要明确的是：IndexedDB未提供在数据库打开状态下直接删除索引的运行时API。删除操作必须同样置于onupgradeneeded事件中，通过objectStore.deleteIndex('indexName')实现。且目标索引必须真实存在，否则将抛出"NotFoundError"错误。
索引删除仅移除了索引结构，不会影响对象存储中的实际数据记录。但此后，所有基于该索引的查询将无法执行，应用层代码需同步调整数据访问逻辑。
- 安全删除实践：推荐采用条件删除模式：
if (store.indexNames.contains('deprecatedIndex')) store.deleteIndex('deprecatedIndex')，增强代码容错性。 - 结构升级与数据迁移：若删除旧索引旨在启用新索引（如将单字段索引替换为复合索引），理想流程是在同一升级事务中，依次完成旧索引删除、新索引创建及必要的数据格式转换，确保结构一致性。
版本升级的事务安全与回滚策略
onupgradeneeded事件中的所有结构变更操作，均在一个升级事务中执行，具备原子性：要么全部成功提交，要么因错误而完全回滚。若索引创建遇到约束冲突或存储空间不足，整个升级将中止，数据库版本维持不变。
需特别注意：IndexedDB规范未定义版本降级或官方回滚机制。一旦版本升级成功提交，无法通过API直接还原至旧版本。
因此在工程实践中，建议关注以下要点：
- 保障操作幂等性：升级逻辑应设计为可重复执行。通过预检查避免重复创建，可应对用户刷新页面导致的重复调用，提升代码鲁棒性。
- 优化耗时操作：尽量避免在升级事务中执行全表扫描等重型数据迁移。可考虑分步实施：先在升级中完成结构变更，再于后续连接中异步处理数据填充或转换。
- 处理连接阻塞：务必监听
onblocked事件。当旧版本数据库连接未关闭时，升级请求将被阻塞。此时应通过界面提示引导用户关闭相关标签页，以获取数据库独占访问权。
兼容旧版本数据的典型处理模式
升级数据库结构时，如何处理已存在的旧版本数据是一大挑战。例如，新增索引所依赖的字段可能在旧记录中缺失，或删除索引后原有查询路径失效。
针对此类兼容性问题，可采用以下几种应对策略：
- 空字段数据处理：若新增索引键路径对应字段在历史数据中为空，可在升级事务中遍历记录，为其填充默认值；或在索引设计时允许忽略无效项，避免查询中断。
- 查询路径平滑迁移：删除索引后，相关查询应迁移至新索引或替代方案。如暂无可替代索引，可降级使用
openCursor()配合客户端过滤（需注意性能影响），或在同一升级周期内规划好新旧索引的过渡方案。 - 模块化迁移推荐实践：将不同版本的数据结构迁移逻辑封装为独立的、可单元测试的函数。在
onupgradeneeded事件中，根据newVersion与oldVersion的差值，按顺序调用相应的迁移模块。这有助于保持代码清晰度与长期可维护性。
