TG咨询应用升级后表结构变了，用户又清理了存储空间，问题可能同时出现在数据迁移和数据重置上。处理安卓应用本地数据库迁移与运行空间重置协调，先要分清“升级旧数据”和“删除本地数据”是两种操作：前者应尽量保留并转换数据，后者通常会清除应用私有目录中的数据库、偏好设置及其他文件。
下面这五个误区适用于使用本地数据库的安卓应用；检查时可结合 Room、SQLite、WAL 和 SharedPreferences 等具体实现。
误区一：改了表结构，版本号却没变
如果应用依据数据库版本号决定是否执行迁移，只修改建表定义而不递增版本，旧数据库可能继续按原结构打开，随后出现缺列、查询失败或写入异常。Room 项目应检查实体定义、数据库版本以及对应的 Migration；直接使用 SQLite 时，则核对数据库版本判断和升级分支是否一致。
- 列出本次变更：新增或删除字段、索引、表及约束。
- 确认旧版本到新版本的迁移路径覆盖了实际用户可能经历的版本跨度。
- 用旧版本生成或保留的数据库副本测试升级，再验证关键查询和写入。
误区二：只测“从上一版升级”
用户可能隔过多个版本才更新。若只验证相邻版本，旧表结构可能没有直达迁移路径。逐一检查支持升级的版本组合；如果允许连续升级，也要确认每一步都可执行且结果正确。不要仅以“应用能启动”作为成功标准，还应核对记录数量、主键、索引和业务字段。
误区三：把清缓存当成清数据
安卓系统设置里的“清除缓存”和“清除存储空间／清除数据”不是同一操作。清缓存针对可再生成的缓存；清除数据通常会重置应用本地状态，包括私有目录内的数据库和偏好设置。界面名称会因系统版本或厂商而异，因此排查前先确认用户执行了哪一种操作。
误区四：重置时直接删数据库文件
运行中删除主数据库文件，可能与连接、事务或 SQLite 的 WAL 日志文件产生冲突。WAL 模式下，尚未合并到主文件的变更可能仍在相关日志中；不能把手工删除单个文件当成可靠重置方式。
- 先停止会继续访问数据库的任务或服务，并让数据库连接按应用设计关闭。
- 通过应用自身的清理流程删除或重建数据，避免只删主文件、遗漏相关状态。
- 重新打开数据库后验证表结构、默认数据和首次启动流程。
需要保留部分设置时，应明确列出保留项与删除项，而非执行无差别清空。SharedPreferences 若保存了数据库版本标记，也要与数据库状态一起检查。
误区五：把迁移失败交给破坏性重建
遇到迁移异常便删除旧库重建，可能让用户数据不可恢复。只有明确允许丢弃本地数据、且数据确实可从可信来源重新取得时，才考虑破坏性重建。否则应记录失败阶段，检查表结构、约束、事务和旧数据兼容性，并保留可恢复方案。
一套可执行的协调检查顺序
- 标明状态边界：区分应用升级、清缓存、清除数据、卸载重装及应用内重置。
- 备份测试数据：准备代表性旧版本数据库副本；备份中若包含偏好设置，也要标注其与数据库版本的对应关系。
- 验证迁移：从每个仍支持的旧结构升级，检查数据、索引和读写结果。
- 验证重置：分别测试只清缓存和清除应用数据，确认保留与删除范围符合设计。
- 检查启动顺序：避免初始化流程先按新结构读取旧库；迁移、状态校验和后续任务应有明确先后关系。
- 记录可诊断信息：记录数据库版本、迁移起止阶段和失败类型，不记录不必要的敏感内容。
做好安卓应用本地数据库迁移与运行空间重置协调，关键是让升级路径可验证、重置边界可解释，并避免运行中绕过数据库机制直接删文件。年度复核时，至少用旧库升级、清缓存、清除数据和异常中断恢复四类场景重新检查。
常见问题
清除缓存会删除数据库吗？
通常不会，缓存与应用数据库用途不同；但具体表现取决于应用把文件放在哪里，遇到问题应核实实际存储路径。
用户卸载重装后，本地数据库还在吗？
应用私有本地数据通常会随卸载移除。若需要跨卸载保留，应设计并验证独立的数据备份或同步机制。
Room 自动迁移能覆盖所有改表情况吗？
不能。自动迁移适用于工具能够识别的结构变化；复杂变更应显式编写迁移逻辑，并用真实旧结构验证结果。
迁移失败后可以直接重建数据库吗？
只有在数据允许丢弃或能够可靠恢复时才适合。否则先保留旧数据并定位失败原因，避免把可修复问题变成数据损失。