写这篇文章的冲动，来自上周一个朋友凌晨三点在群里发的崩溃截图。他刚给客户上线一个Django项目，数据库迁移时表结构冲突，生产环境直接挂了。客户数据丢了不说，还得连夜回滚。这种场景，但凡做过Django开发的人，多少都经历过。Django的迁移系统，OrM层做得再牛，真到了线上，坑一点都不少。
很多人觉得Django迁移就是跑个makemigrations和migrate，简单得很。但线上环境哪有那么简单？你有存量数据，有正在跑的请求，有多个环境之间的版本差异。一个不小心，migrate跑下去，数据库锁表、字段冲突、数据丢失，哪样都能让你加班到天亮。这篇文章，我就把自己踩过的坑和总结出来的方法，掰开揉碎了讲给你听。三句话：先看准当前状态，再动手做迁移，验证无误才上线。
第一坑：迁移文件混乱。Django的迁移文件默认存在app下的migrations文件夹，按时间戳和序号排列。但多人协作时，拉代码、合分支，很容易出现迁移文件重名、序号冲突、依赖断裂。我见过一个团队，三个人同时改了同一个模型，各自生成了迁移文件，合完代码后，migrate跑报错，说迁移依赖找不到。解决办法：合代码前，先跑一遍makemigrations --dry-run，看看有没有异常合并。如果发现冲突，手动调整依赖顺序，或者删掉多余的迁移文件，重新生成一个干净的合并迁移。线上环境，迁移文件越精简越好，别攒一堆零散的。
第二坑：字段变更导致数据丢失。Django的migrate跑的时候，默认会做字段映射。你改了个字段类型，比如从CharField改成IntegerField，如果没有指定default或者null=True，migrate会直接报错。更坑的是，你删了个字段，migrate跑完，那列数据就没了。线上数据丢了，客户不找你拼命才怪。解决办法：每次修改模型前，先备份数据库。如果只是新增字段，加个null=True或default值就行。如果要改字段类型，分两步走：第一步，新增一个字段，用迁移把旧数据迁移过去；第二步，再跑一个迁移，删掉旧字段。这样每一步都有回滚余地。
第三坑：迁移顺序依赖过深。Django的迁移文件之间有个依赖链，每个文件都记录了它依赖哪个前序文件。如果你手动调整了顺序，或者合并了多个迁移，依赖关系可能乱掉。跑migrate时，Django会按依赖顺序执行，一旦某个迁移失败，后面的全卡住。线上环境，你不可能等它一个个重试。解决办法：用django-extensions的showmigrations命令，看当前所有迁移的状态。发现有未应用的迁移，先检查依赖顺序。如果依赖乱了，可以手动编辑迁移文件的dependencies列表，把顺序理顺。更稳妥的做法是，定期做迁移文件的squash，把多个小迁移合并成一个大的，减少依赖深度。
第四坑：migrate跑一半中断。线上数据库迁移，最怕的就是跑一半网络断了、服务器重启了。Django的迁移是原子性的吗？默认不是。Django的migrate命令会在每个迁移文件外面包一层事务，但如果你用的是MySQL的MyISAM引擎，事务不生效。PostgreSQL和InnoDB支持事务，但迁移文件里的操作如果跨表，事务边界可能出问题。解决办法：用migrate --run-syncdb参数可以跳过已应用的迁移，只跑新的。但更靠谱的是，每次迁移前，手动用python manage.py dbshell备份数据库。如果迁移中断，先检查哪些迁移已经应用了，哪些没应用，用migrate appname 000xpreviousmigration回退到安全位置，再重新跑。
第五坑：数据迁移脚本写死。有时候你需要把旧数据转成新格式，比如用户手机号从11位改成带区号。Django提供了RunPython或RunSQL，可以在迁移文件里写自定义逻辑。但很多人写脚本时，直接硬编码数据，或者依赖当前模型的状态。一旦模型结构变了，脚本就跑不了。解决办法：数据迁移脚本里，用apps.getmodel获取历史模型，别用当前项目的model。用apps.getmodel('yourapp', 'YourModel')，这样即使在迁移过程中，模型结构变了，也能拿到正确的历史版本。脚本里加个try-except，捕获异常后记录日志，别让一条脏数据卡死整个迁移。
第六坑：线上迁移不通知团队。很多团队，一个人跑完migrate，其他人在不知道的情况下拉代码，本地迁移和线上对不上。或者测试环境跑成功了，线上环境跑失败了，因为数据量不同。解决办法：建立迁移的沟通机制。每次迁移前，在群公告或文档里写明：迁移哪个app、迁移文件编号、预计耗时、回滚方案。跑完迁移后，用python manage.py showmigrations --list确认所有迁移都应用了。线上迁移最好在低峰期操作，比如凌晨，万一出问题，有时间回滚。
第七坑：忽略数据库版本差异。Django迁移生成的SQL，在不同数据库引擎下表现不一样。SQLite不支持某些字段类型，MySQL的字符集设置会影响字段长度，PostgreSQL的序列自增行为也不同。开发环境用SQLite，线上用PostgreSQL，迁移文件可能跑不通。解决办法：开发环境和线上环境尽量保持数据库引擎一致。如果实在不行，用python manage.py sqlmigrate appname 000x查看生成的SQL，手动复制到线上数据库跑。别信Django会帮你自动适配所有差异。
写到这里，你可能觉得Django迁移太危险了。其实不然，只要养成三个习惯，这些坑都能避开。第一，每次改动模型前，先跑makemigrations --dry-run看变更内容，确认无误再生成文件。第二，线上迁移前，用pg_dump或mysqldump备份数据库，哪怕只花10秒钟。第三，迁移完成后，用showmigrations和自写脚本验证数据完整性。这三步走下来，线上数据升级基本稳了。
上周那个朋友，后来我教他用squashmigrations合并了迁移文件，又用RunSQL写了个数据校验脚本。再跑迁移时，提前备份、分步执行、验证数据，20分钟搞定。他感慨说，原来不是Django不行，是自己太糙。Django迁移系统设计得已经很聪明了，但聪明不代表万能。你要做的，不是抱怨它坑多，而是学会跟它打交道。记住，迁移不是写代码，是处理数据。数据丢了，代码写得再好也白搭。
