一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 IndexedDB 结构变更只能在升级事务中执行且会被旧连接阻塞。大数据重写放进 upgrade 会长时间锁库并可能被浏览器终止。
数据设计需要同时说明原子写入、并发读写、版本迁移、崩溃恢复和清理策略。能成功保存一次不代表断电、空间不足或旧版本重开时仍保持一致。
设计时必须回答的问题
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 升级事务只创建 store/index 与迁移标记；数据转换在打开后分批执行并记录 cursor，BroadcastChannel 请求旧标签关闭连接。
- 先定义正常、降级、取消和失败四类终态，再让界面、存储与指标消费同一状态。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“IndexedDB Schema Migration：升级中断后仍能安全打开页面”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
边界情况不是附加项
生产问题往往发生在两个正确动作同时到达时。需要逐条检查迟到消息、重复执行、资源耗尽和版本交叉，而不是只补当前堆栈显示的那一行。
- 新代码假定后台迁移已完成会读取半新半旧记录；旧版本应用在 schema 升级后写入又可能生成无法解析数据。
- 失败被压成一个布尔值，调用方无法区分可重试、需用户介入与永久拒绝，最终形成无限循环。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
用证据确认它真的可用
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 在每个批次和 versionchange 中途关闭页面，保留旧标签并回退应用版本，验证重新打开、继续迁移和兼容提示。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 用故障注入验证告警先于用户投诉触发，并确认值班人员能从有限证据定位到具体阶段。
当实现能够安全降级、重复执行不产生额外副作用、故障指标早于投诉出现时，这项能力才算具备长期维护价值。