如何解决因修改迁移文件名导致的Django数据库迁移报错问题

核心原因说明 #

Django会在数据库的django_migrations表中记录所有已执行的迁移文件信息。你在dev环境已经运行过旧名称的删列迁移后，旧迁移已经被标记为已完成；你修改迁移文件名并删除旧迁移文件后，Django判定新文件名的迁移未被执行过，再次部署时会尝试重复执行删列操作，而对应列已经被删除，因此触发报错。stage和prod环境从未运行过旧名称迁移，所以新迁移执行正常。

操作步骤 #

• 第一步：确认改名后的迁移文件内容、依赖配置和旧迁移完全一致，没有额外修改，避免多环境迁移逻辑不一致。
• 第二步：在dev环境执行fake迁移命令，标记新迁移为已执行，不会真实执行SQL操作：

  python manage.py migrate --fake <你的应用名称> <新迁移文件的数字前缀>
  

  举个例子：如果你改名后的迁移文件名为0018_delete_user_unused_fields.py，对应应用为user，就执行：

  python manage.py migrate --fake user 0018
  

• 第三步：验证迁移状态，执行如下命令确认新迁移已经被标记为已执行：

  python manage.py showmigrations <你的应用名称>
  

  若新迁移前显示[X]则说明标记成功，再次部署dev环境即可正常通过。

注意事项 #

• 上述操作仅需在dev环境执行，stage、prod环境已经正常运行过新迁移，无需额外处理。
• 后续已经在任意环境执行过的迁移文件，不要随意修改文件名或内部逻辑，避免出现多环境迁移状态不一致的问题。
• 确认代码仓库中已删除旧名称的迁移文件，仅保留改名后的新版本，避免后续出现迁移冲突。

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