Django迁移失效问题求助：修改模型后需重建数据库

一、先从报错抓根源 #

每次执行migrate报错时，别直接删库，先把完整报错信息拉出来看关键词：

• 要是出现column already exists：十有八九是你手动改过数据库（比如直接跑SQL加字段），导致Django的迁移记录和实际库结构对不上
• 要是no such table/column：要么是migrations文件夹里的文件被删改了，要么是django_migrations表的记录乱了，Django以为某些迁移没执行过
• 要是cannot add NOT NULL column with default value：新增非空字段时没给默认值，旧数据没法填充，自然执行失败

另外，直接查数据库里的django_migrations表，把里面的记录和本地migrations文件夹里的文件对比：看看有没有本地有文件但表中没记录的（没执行），或者表中有记录但本地文件被改了的（记录和实际操作不符）。

二、常见问题的修复方法 #

1. 迁移记录和库结构不一致 #

如果你手动改了数据库导致报错，直接用python manage.py migrate --fake <app_name> <migration_number>把对应的迁移标记为已执行。比如你要标记blog app的0003号迁移，就跑python manage.py migrate --fake blog 0003。这个命令只改django_migrations表，不会动数据库，所以得先确保实际库结构和迁移文件内容完全一致再用。

2. 新增非空字段报错 #

新增非空字段不能一步到位，得拆三步：

1. 先把字段设成null=True，跑python manage.py makemigrations生成迁移，执行migrate
2. 批量给旧数据填充这个字段的值
3. 再把字段改成null=False，生成新迁移并执行

要是已经报错了，先回滚到上一个正常的迁移版本：python manage.py migrate <app_name> <previous_migration_number>，再按上面的步骤来。

3. 迁移文件被误删或修改 #

如果migrations文件丢了或者被改了，先从Git（或其他版本控制工具）里恢复对应的文件，确保和生产环境django_migrations表的记录一致。要是没版本控制，就对比本地开发环境和生产环境的migrations文件，补全缺失的，然后用--fake标记为已执行。

三、别再踩坑的正确操作流程 #

• 绝对不要手动改数据库结构，所有表、字段的变更都通过修改模型，再跑makemigrations和migrate完成
• 已执行过的迁移文件别乱删、别乱改，哪怕看起来没用
• 生产环境执行迁移前，必须在测试环境完全复现一遍，确认没问题再操作
• 发布前把所有未执行的迁移文件同步到生产环境，再执行migrate

内容的提问来源于stack exchange，提问作者Yome