3. Schema导出与版本控制归纳总结
咱们继续聊Room迁移。这节内容，说白了就是解决一个核心问题：怎么让Room知道，数据库从旧版本到新版本，具体变了什么？
答案就在Schema文件里。它就像一份数据库的“DNA蓝图”。
3.1 Schema文件是什么？为什么重要？
每次你改了Entity，重新编译项目，Room都会生成一个JSON文件。里面详细记录了所有的表结构、字段名、类型、索引、外键等等。
它的关键作用有两个：
- 作为迁移验证的标准答案 —— Room在跑测试时，会用老版本的Schema生成一个“假”数据库，然后执行你的Migration，最后拿结果跟“新版本Schema”对比。不一致？测试就挂了。
- 作为团队协作的依据 —— 有了Schema，不同开发人员的本地数据库版本就不会对不上。
我见过最惨的Case：有个项目没开启Schema导出，结果两个开发各改各的表，合并代码后才在测试环境发现数据库字段对不上。那感觉，就像你拿着地图，我拿着导航，最后发现去的是两个不同的目的地。
3.2 如何导出Schema？
配置非常简单。在你的build.gradle（模块级）里，给Room加上schemaLocation参数：
room {
schemaLocation "$projectDir/schemas"
}这行配置做了两件事：
- 自动生成：每次编译，Room会把当前版本号的Schema输出到
schemas/目录下。 - 按版本命名：文件名是
你的包名/数据库名.json，比如com.example.app/AppDatabase.json。版本号增量时，会生成多个文件。
举个例子，如果你的数据库从版本1升到2，目录结构大概是这样：
app/schemas/
├── com.example.app/
│ ├── 1.json
│ └── 2.json
└── ...一个小建议：记得把这个目录加到版本控制里（Git）。不然换了电脑，你本地的Schema就丢了。我之前就干过这种蠢事。
3.3 版本控制策略
| 场景 | 我的做法 | 踩过的坑 |
|---|---|---|
| 第一次导出 | 直接开启schemaLocation，编译一次。检查生成的JSON是否完整。 |
—— |
| 新增表/字段 | 先把version升级，编译，看自动生成的JSON。然后手动写Migration。 |
忘了改version，导致Schema重复覆盖。 |
| 删除字段 | 同样先编译，看JSON里字段是否消失。再写destructiveMigration()或手动迁移。 |
有一次删字段没删干净，Schema里还残留，测试死活过不了。 |
| 多人协作 | 让每个开发者都本地编译并提交Schema文件。用Git diff看字段变更。 | 两人同时加了不同字段，合并后Json冲突。解决方案：手动合并，确保都保留。 |
你想想看，如果没有版本控制，你的Schema文件就乱成一锅粥。每次Migration失败，你都得从头排查。
3.4 核心流程总结
下面这张图，是我多年项目经验的浓缩。它把Schema导出、版本控制、迁移测试串在了一起。
为什么一定要用Schema做自动化验证？ 手动写Migration时，99%的坑都出现在“我以为字段没变，但实际上变了”。Schema对比能帮你在毫秒级发现问题。
3.5 实战中的小技巧
- 不要依赖自动Migration：自动Migration只能处理简单场景（比如改字段名）。一旦涉及表结构重构，必须手写。
- 提交前检查JSON：每次提交Schema前，扫一眼JSON。确认字段、索引、外键没异常。就花30秒，能省下几小时。
- 利用Git diff：团队里有人改了Entity，Git diff会高亮展示。配合Schema文件，你一眼就能看出改了什么。
警告：切忌粗暴覆盖。我曾经在迁移测试里，为了省事，直接把老版本Schema的内容复制粘贴到新版本里。结果测试是过了，但上生产后，用户数据全部丢失。这事之后，我每次改Schema都至少跑两遍测试。
嗯，掌握好Schema导出和版本控制，你的Room迁移之路就稳了一大半。剩下的，就是耐心写Migration、跑测试、看结果。说白了，这就是一个“发现不一致 -> 修复不一致”的循环。