Django执行makemigrations和migrate后无法应用字段null=True修改的问题求助

我之前也碰到过一模一样的糟心事！明明改了模型字段的null=True，跑了makemigrations和migrate，数据库里的字段还是死死保持着NOT NULL，手动写的空迁移显示应用了也没效果，简直头大。结合我当时踩的坑，给你几个靠谱的解决思路，都是亲测有效的：

先搞懂为什么手动迁移没生效 #

Django的迁移系统是基于状态对比的，不是单纯看你改了什么代码。如果Django的迁移状态表（django_migrations）里记录的状态，和你手动写的迁移的目标状态一致，哪怕数据库实际不是这样，它也只会标记迁移为已应用，不会真的执行ALTER TABLE语句。这就是你手动写的迁移没效果的核心原因——Django以为当前已经是null=True的状态了。

方法一：手动修正数据库+同步迁移状态（适合少量字段修改） #

这个方法最快，适合你这种只有几个字段要改的情况，前提是一定要先备份数据库！

1. 直接在数据库里执行SQL语句修改字段：
   先确认你的表名（Django默认是app名_模型名小写，比如sellersapp_sellers），然后执行：

   ALTER TABLE sellersapp_sellers ALTER COLUMN selling_name DROP NOT NULL;
   ALTER TABLE sellersapp_sellers ALTER COLUMN zip_code DROP NOT NULL;
   

   执行完后去数据库里检查字段的NOT NULL属性是不是已经去掉了。

2. 同步Django的迁移状态：
   如果你之前已经手动创建了那个fix_nullable_fields迁移，现在用--fake参数告诉Django“这个迁移的修改已经完成了，只是标记一下”：

   python manage.py migrate --fake sellersapp 000X_fix_nullable_fields
   

   把000X换成你那个迁移文件的实际编号就行。

方法二：重置迁移状态，重新生成正确的迁移（更规范，适合状态严重不一致的情况） #

如果担心手动改SQL有风险，或者以后还要避免类似问题，可以用这个方法彻底同步迁移状态和数据库：

步骤1：备份数据和现有迁移 #

• 先把整个数据库备份一遍，绝对不能省！
• 把sellersapp/migrations文件夹里的所有文件（除了__init__.py）复制到一个备份文件夹（比如sellersapp/migrations_backup），然后删掉原文件夹里的这些文件。
• 用SQL命令清空django_migrations表中属于sellersapp的记录：

  DELETE FROM django_migrations WHERE app = 'sellersapp';
  

步骤2：同步初始状态 #

• 暂时把models.py里的null=True去掉，恢复成和数据库当前一致的状态（也就是字段没有null=True）。
• 生成初始迁移：

  python manage.py makemigrations sellersapp
  

  这会生成一个0001_initial.py，完全对应数据库当前的字段状态。
• 用--fake-initial标记这个迁移为已应用（不用实际修改数据库，因为数据库已经是这个状态了）：

  python manage.py migrate --fake-initial sellersapp
  

步骤3：生成并应用字段修改的迁移 #

• 把models.py改回null=True的状态。
• 现在生成新的迁移，Django会准确检测到字段的变化：

  python manage.py makemigrations sellersapp
  

  打开生成的迁移文件，你会看到里面有正确的AlterField操作，对应字段的null=True修改。
• 最后执行迁移，这次Django会真正执行ALTER TABLE语句修改数据库：

  python manage.py migrate sellersapp
  

最后提醒 #

不管用哪种方法，备份数据库都是第一要务！数据安全永远是第一位的。另外，以后尽量不要手动修改迁移文件，除非你非常清楚Django迁移系统的工作原理，不然很容易造成状态不一致。

内容来源于stack exchange