应用更新后崩溃：Room迁移未正确处理，无Found TableInfo

一、迁移代码的核心问题 #

1. 手动事务干扰Room的事务管理 #

在MIGRATION_3_4中手动执行了BEGIN TRANSACTION;和COMMIT;，但Room在执行迁移时会自动启动并管理事务。手动嵌套事务会破坏Room的事务逻辑，可能导致SQL操作的提交/回滚行为异常，比如表删除后重建操作未生效，或者后续更新语句执行失败。

2. DROP+CREATE表的结构校验风险 #

直接删除MyEntity对应表后重建的方式，可能导致Room无法正确追踪表结构的变化。尤其是当后续搭配自动迁移使用时，手动重建的表结构可能和Room根据实体类生成的预期结构存在隐性差异（比如列顺序、约束细节），触发结构校验失败。

3. 手动迁移与自动迁移的兼容性冲突 #

同时使用手动迁移和自动迁移时，手动修改表结构的操作（如删表重建、ALTER）可能让自动迁移无法正确识别当前数据库的状态，导致Room预期的表结构与实际数据库结构不匹配，最终触发Migration didn't properly handle异常。

二、崩溃日志中Found的TableInfo为空的原因 #

当数据库中目标表（promotion_entity）不存在时，Room的结构校验会显示Found部分为空。这种情况大概率是因为MIGRATION_3_4中的手动事务执行异常：

• 可能是DROP TABLE执行后，CREATE TABLE因SQL语法错误、事务冲突等原因未成功执行；
• 也可能是手动COMMIT操作失败，导致事务回滚，最终表被删除但未重建。

三、修复建议 #

• 移除手动事务代码：删除MIGRATION_3_4中的BEGIN TRANSACTION;和COMMIT;语句，让Room自动管理迁移事务，确保整个迁移过程的原子性（要么全部成功，要么全部回滚）。
• 优先使用ALTER TABLE替代删表重建：如果只是修改表结构，尽量用ALTER TABLE添加/修改列，而非删表重建，这样Room能正确追踪结构变化，避免校验异常。若必须删表重建，需确保重建的SQL语句与MyEntity实体类的定义完全一致（包括列顺序、约束、数据类型等）。
• 统一迁移策略：尽量避免手动迁移与自动迁移混合使用。若必须混合，需保证手动迁移后的表结构与Room实体的最新定义完全匹配，且覆盖所有可能的版本升级路径测试。
• 完善测试覆盖：当前仅测试了testLatestMigration，但实际用户可能从更早版本（如版本3）直接升级到最新版本，需补充全版本路径的迁移测试，覆盖真实场景。

内容的提问来源于stack exchange，提问作者Jaloliddin Gulomov