搞开发的兄弟都知道，数据库版本管理这事儿有多头疼。项目迭代快，表结构三天两头要改，加个字段、改个类型、甚至重构整个关系，手动在数据库里折腾几回就乱成一锅粥。尤其是团队协作的时候，你本地改了表结构，同事那边还得手动同步，一不小心就出生产事故。EF Core的数据库迁移命令，就是专门来治这个毛病的。它让你用代码来定义数据库的每一次变化，然后自动生成对应的SQL脚本，再同步到数据库里。说白了，就是把数据库版本管理这件事儿，从“手工操作”变成了“代码驱动”，从此告别那些让人抓狂的版本冲突和数据丢失。
先说说最基础的那几个命令吧。是第一步，你改了实体类之后，跑一下这个命令，EF Core就会对比当前数据库的状态和最新的模型，生成一个迁移文件。这个文件里记录了这次改动的内容，比如新增了一张表、删了一个索引、改了某个字段的数据类型。文件名会带上时间戳和你的命名，方便追溯。然后是，这个命令把刚才生成的迁移文件应用到数据库里，直接执行。如果你只是想预览一下会执行什么SQL，可以用生成一个脚本文件，交给DBA审核或者手动执行。这三个命令配合起来，就能完成一个完整的数据库变更周期。
不过光会用基础命令还不够，实际工作中经常会遇到一些坑。比如你改了实体类，但忘了跑，直接跑，EF Core会告诉你没有待应用的迁移。这时候别慌，先检查一下模型和数据库是否一致，或者看看迁移文件里有没有遗漏的改动。另一个常见问题是迁移冲突，尤其是多人开发的时候。两个人同时改了同一个实体类，各自生成了迁移文件，合并代码后就会出现冲突。解决办法是让其中一个同事先删掉自己的迁移文件，重新生成，或者用回退到上一个版本再合并。这些坑踩多了，自然就记住了。
再进阶一点，你得学会处理数据迁移。比如把一张表拆成两张，或者把某个字段的值迁移到另一个字段里。单纯的只负责结构变更，不处理数据。这时候就需要在迁移文件里手动写方法，插入自定义的SQL脚本。比如你要把“用户名”字段拆成“名”和“姓”两个字段，可以在方法里写一段UPDATE语句，把旧数据拆开填进去。这样数据库结构变了，数据也同步过去了。别偷懒，数据迁移这块不处理好，上线后补数据能把你累死。
版本回退也是高频需求。有时候你发现刚部署的迁移有问题，需要回滚到上一个版本。这个命令能直接回退到指定的迁移版本，它会自动执行方法里的代码，把改动撤销掉。但要注意，方法不是万能的，比如你删了一列数据，方法只会加回列，不会恢复被删掉的数据。所以回退前最好先备份数据库，或者手动写个恢复数据的脚本。另外，生产环境回退要格外谨慎，建议先在测试环境演练一遍。
团队协作时，迁移文件的提交和同步也很有讲究。每个人的本地开发环境可能不同，迁移文件里包含了数据库快照，如果大家不统一，很容易出问题。最佳实践是：所有迁移文件都提交到版本控制系统，团队成员在拉取代码后，跑来同步本地数据库。如果遇到迁移文件冲突，不要手动改文件，而是用回退到共同基线，再重新生成。还有个小技巧，可以在项目里加一个自动迁移的初始化脚本，让新同事一拉代码就能建库，省得手把手教。
说说生产环境的迁移策略。别直接在服务器上跑，那太危险了。生产环境应该用生成SQL脚本，交给DBA审核，然后在维护窗口执行。脚本里包含了所有迁移的SQL，执行顺序是固定的，不会出错。如果数据库很大，迁移可能会锁表，影响业务，这时候可以考虑分批迁移或者用影子表方案。影子表的意思是，先创建新表，把数据迁过去，再切换表名，这样对业务影响最小。EF Core的迁移命令虽然强大，但生产环境的操作一定要多留个心眼。
掌握EF数据库迁移命令，就像给数据库版本管理装了个方向盘。从基础命令到数据迁移，从冲突解决到生产部署，每一步都有章可循。刚开始可能会觉得命令多、参数复杂，但用熟了之后，你会发现以前那些手动改数据库的焦虑全没了。代码即文档，迁移即历史，整个数据库的变更轨迹清清楚楚。下次项目迭代，别再对着数据库发愁了，打开终端，敲几个命令，轻松搞定版本变更和数据同步。
