刚接触 Django 那会儿，最让我头疼的就是数据库迁移。明明照着文档一步步来，结果不是字段类型对不上，就是表结构乱成一锅粥。后来跟几个老程序员聊了聊，才发现这东西说难也不难，关键是要搞懂它到底在干嘛。说白了，迁移就是 Django 把 Python 代码里的模型定义，翻译成数据库能懂的 SQL 语句。这个过程看似简单，但坑多着呢——尤其是项目大了、改动频繁时，一个不小心就能把开发环境玩崩。
先聊聊迁移文件是怎么生成的。你运行 时，Django 会对比当前模型和数据库里的实际结构，找出差异，然后自动生成一个迁移文件。这个文件放在 app 目录下的 文件夹里，名字像 、 这样的。每个文件里都是 Python 代码，而不是 SQL，这点特别重要。因为 Python 代码可以跨数据库——开发时用 SQLite，生产用 PostgreSQL，迁移文件照样能用。我见过有人直接改数据库表结构，然后手动写迁移文件，结果部署时全崩了。千万别这么干，老老实实用 Django 的迁移命令，它比你聪明。
然后就是执行迁移了。 这个命令会把所有还没执行过的迁移文件挨个跑一遍。Django 靠一张叫 的表记录哪些迁移已经执行过了。所以如果不小心删了某个迁移文件，或者手动改了数据库，这张表就会和实际状态对不上，进而花大把时间排错。我有个同事就干过这事——他嫌某个迁移文件碍眼，直接删了，然后重新 ，结果 Django 以为那个迁移没执行过，又跑了一遍，字段重复创建，表结构乱成一团。花了半天才恢复回来。
迁移文件里最常用的操作是创建表、加字段、改字段类型。但有些操作特别容易踩坑，比如给已有数据的表加非空字段。想象一下，数据库里已经有 100 条记录，你现在要加一个 ，字段不能为空，但老记录没有值，Django 会要求提供默认值。这时可以在模型里设置 或者 ，但要注意， 在 和 里要慎用，因为 Django 的惯例是“没有数据就用空字符串”，而不是 NULL。这个习惯和其他框架不太一样，刚开始很容易搞混。
更麻烦的是改字段类型。比如原来是 ，现在想改成 。直接改模型再迁移，Django 会报错说类型不兼容。这时需要写数据迁移——手动写一个迁移文件，把旧数据逐条转成新格式。比如年龄字段原来存整数，现在要改成字符串，就得写个循环把每条记录的年龄转成字符串再保存。这类数据迁移文件是独立的，放在正常的结构迁移后面执行。写的时候要注意性能，数据量大就别用循环，直接用 批量更新，否则几十万条数据会把服务器卡死。
还有个坑是外键和关联表的迁移。Django 的 ORM 让关联查询非常方便，但迁移时外键约束就会成为麻烦。比如订单表关联用户表，现在要改用户表的主键字段类型，Django 会先检查有没有外键依赖。如果有，它不会直接改，而是先删掉外键约束，改完字段再加回来。听起来简单，实际执行时如果数据量太大，删约束加约束的操作可能会锁表，导致线上服务短暂不可用。我见过一个案例，某团队在生产环境直接跑迁移，结果订单表被锁了五分钟，用户下不了单，投诉电话打爆了。后来他们学乖了，每次改外键相关的字段，都先停掉写操作，跑完迁移再恢复。
迁移文件多了之后，管理也会变得头疼。比如开发了三个月，生成了上百个迁移文件，每次部署都要跑一遍，速度越来越慢。这时可以压缩迁移——把多个小迁移合并成一个大的。Django 提供了 命令，例如 ，就会把 0010 到 0020 之间的所有迁移合并成一个新文件。但注意，压缩后旧的迁移文件别急着删，先在测试环境跑完整迁移流程，确认压缩后的迁移能正确还原数据库状态，再清理旧文件。
说说生产环境的迁移策略。永远别在生产环境直接跑 ，除非确认没有数据丢失的风险。正确的做法是：先在开发环境模拟一遍，确保所有迁移文件都能正常执行；然后备份生产数据库；接着用 参数跳过已经执行过的迁移。例如你加了一个新字段，迁移文件是 0005，但生产环境已经跑到 0004，你可以先 到 0004，再正常执行 0005。这样既不会重复执行已经跑过的迁移，又能安全地把新改动部署上去。我见过有人图省事，直接在生产环境 ，结果因为迁移文件里的默认值和现有数据冲突，导致整个迁移失败，回滚都来不及。
说到底，Django 迁移是个好工具，但它不是万能的。你得理解它背后的逻辑，知道什么时候该用命令，什么时候该手动干预。特别是遇到复杂的数据库改动时，别急着敲命令，先想清楚迁移文件会怎么执行，会不会锁表，会不会丢数据。多花五分钟想清楚，比花两小时回滚要划算得多。毕竟，数据库一旦出问题，恢复起来就是一场噩梦。
