Capacitor项目升级到v6版本时IndexedDB数据丢失问题分析

问题背景

在将Capacitor核心库从v5.0.5升级到v6.2.0版本时，开发者遇到了一个Android平台上IndexedDB数据丢失的问题。具体表现为使用@ionic/storage存储的数据在新版本中无法访问，但回退到旧版本后数据又能恢复。这个问题在Web平台上无法复现。

问题现象

1. 应用升级后，通过Chrome开发者工具检查发现IndexedDB中的数据确实被清空
2. 但Android系统设置中显示的应用存储空间并未减少
3. 数据丢失仅发生在Android平台，Web平台不受影响
4. 使用@ionic/storage库并以IndexedDB作为存储驱动

根本原因

Capacitor 6.0.0版本引入了一个重大变更：默认的URL scheme从http改为https。这个变更导致了IndexedDB数据库的访问路径发生变化，使得应用无法访问之前版本创建的数据存储。

IndexedDB的数据库访问是基于origin(协议+域名+端口)的，当协议从http变为https后，系统会认为这是一个全新的origin，因此创建了一个新的数据库实例，而不是访问原有的数据库。

解决方案

对于需要保留旧版本数据的应用，在升级到Capacitor 6.x时，可以通过以下方式解决：

1. 在Android项目的capacitor.config.json或capacitor.config.ts中显式指定使用http scheme：

{
  "android": {
    "scheme": "http"
  }
}

2. 对于新应用或可以接受数据丢失的情况，可以直接使用默认的https scheme

技术原理深入

Capacitor作为混合应用框架，在Android平台上通过WebView运行Web代码。IndexedDB作为Web存储API，其数据隔离机制遵循同源策略。当应用的URL scheme改变时：

• 协议(http/https)变化被视为不同的origin
• 浏览器/WebView会为每个origin创建独立的存储空间
• 旧数据仍然存在于设备上，但新版本应用无法访问
• 系统存储统计显示空间未减少，因为旧数据未被真正删除

最佳实践建议

1. 对于生产环境应用，升级前应评估数据迁移方案
2. 考虑实现数据备份/恢复机制，特别是对关键用户数据
3. 测试升级时，不仅要验证功能，还要检查数据持久性
4. 关注框架的升级指南和重大变更说明

总结

Capacitor 6.x的scheme变更虽然提升了安全性，但也带来了数据兼容性挑战。开发者需要理解底层存储机制，在升级时做出适当配置调整，确保用户体验的连续性。这个问题也提醒我们，在混合应用开发中，Web存储API的行为可能因平台实现和框架配置而有所不同，需要特别关注。