我刚入行那会儿，最怕听到的一句话就是“需求改了，数据库表结构要调整”。那时候用的还是手写 SQL，改个字段名都得小心翼翼，生怕一个 DROP 下去，生产环境的数据就全没了。后来接触了 Django，发现这个世界居然有“数据库迁移”这么个好东西——你只管改模型，剩下的交给 Django，它会自动生成 SQL 脚本并执行，关键是还能保留现有的数据。说真的，第一次用 和 时，我盯着终端输出的几行 “OK”，愣是看了半天，心里想：这就完了？数据没丢？表结构真的改过来了？从那以后，我再也没手写过 。Django 的迁移系统，说白了就是把模型定义和数据库结构之间的“翻译工作”自动化，而且翻译得比手工靠谱。
但别以为迁移就是运行两个命令那么简单。第一次在项目里加字段时，我就踩了大坑——往 模型里加了一个非空字段，直接跑 ，结果终端报错：“你在已有数据的表里加非空字段，又不给默认值，我怎么办？”我当时懵了——对啊，数据库里已经有千余条用户记录，新字段没有值，Django 自然不知道该填什么。后来才知道，解决办法很简单：要么给字段设置 参数，要么设 允许为空，甚至可以使用 等关系字段。更高级的做法是先生成迁移文件，然后手动编辑其中的 操作，加入一个默认值函数，比如给所有已有用户的新字段设置一个默认的 UUID。文档里都有这些细节，只是如果不亲自踩一次坑，根本记不住。
说到踩坑，还有一个经典场景是改字段类型。比如原来是 ，现在想改成 ，字段名不变。这在纯 SQL 里只是一条 ，但在 Django 迁移里必须小心。Django 默认会生成 操作，但如果原来的 中存了非数字的字符串（比如 “abc”），迁移执行到一半就会报错。我有个同事就这么干过，结果迁移失败后，数据库处于“半迁移”状态，表结构乱了，数据也丢失了一部分。后来我们学乖了，遇到这种类型转换时，先手动写一个数据迁移脚本，把旧数据清洗一遍，确保所有值都能转成目标类型，再跑结构迁移。Django 的 操作正是为此设计的，你可以写一个函数遍历所有记录，把字符串转成整数，无法转换的设默认值或抛异常。
迁移文件本身也是好东西，但很多人把它当黑盒。你有没有打开过 目录下的 、 之类的文件？里面其实就是一堆 Python 列表，每个元素是一个迁移操作，比如 、、。这些操作按顺序执行，Django 会把每个迁移是否已执行记录在 表里。所以如果不小心删了某个迁移文件，然后想回滚到那个状态，就会非常痛苦。建议养成一个习惯：每次生成迁移文件后，先打开看看里面的操作是否符合预期，尤其是涉及数据删除的操作，如 或 。确认无误后再提交到版本控制，千万别把“删表”这种操作混进一堆加字段的迁移里。
说句实话，团队协作时迁移文件最容易出问题。你和同事同时修改模型，各自生成迁移文件后提交到同一个分支，合并时就会发现两个迁移文件的依赖顺序乱了。比如你的 依赖 ，同事的 也依赖 ，合并后 Django 不知道该先执行哪个，会报“多个迁移文件有相同依赖”的错误。解决办法是手动修改其中一个迁移文件的 ，让它依赖另一个。例如把 的 改成 ，这样 Django 就会先跑年龄字段再加邮箱字段。更省心的做法是：在合并分支后统一重新生成迁移文件，删除冲突的迁移，再跑一次 生成一个新的合并迁移。
数据迁移是另一个容易被忽略的领域。很多人以为 Django 迁移只负责表结构，实际上它同样支持数据迁移。比如有一个 模型，原来只有 （），现在要拆成 和 两个字段，并把旧的 按一定规则拆分到新字段里。光靠结构迁移搞不定，需要写一个数据迁移脚本。方法是使用 生成空迁移文件，然后在其中加入 操作，编写函数遍历所有 记录，读取旧字段的值，计算后写入新字段。跑完后别忘了删除旧字段。这个流程听起来有点复杂，但写一次就熟练了，而且比手写 SQL 更新数据安全得多，因为 Django 的迁移系统会帮你管理事务，出错还能回滚。
我总结的经验是：永远不要在生产环境上直接跑 。不管你对迁移文件多自信，都要先在本地或预发布环境跑一遍，确认没有报错、数据也没丢。尤其是带数据迁移的脚本，一定要在测试环境验证逻辑是否正确。我有个朋友在生产环境跑了一个数据迁移脚本，结果脚本里一个条件判断写错，把所有用户的状态字段都设成了 “已删除”，导致线上业务停了两个小时。事后排查发现问题就在那段代码。所以我的做法是：每次上线迁移前，先备份数据库，然后在本地的副本上跑一遍迁移，确认日志里没有 或 ，再用生产环境的备份跑一次，最后才真正执行。虽然麻烦点，但比起数据丢失或业务中断，这点时间完全值得。记住，迁移是工具，不是魔法，用得好能省心，用得不好会让你加班到凌晨三点。
