重新生成Django迁移后出现InconsistentMigrationHistory异常求助

我之前也踩过这个坑——删了旧迁移文件重新生成后，migrate直接抛出这个异常，明明看起来依赖关系没问题，也没循环依赖。咱们一步步拆解问题、解决它：

为啥会出现这个异常？ #

说白了就是数据库里的django_migrations表还留着旧的迁移记录，但你本地的迁移文件已经被完全重置了。Django会对比这两者的历史，发现对不上，就判定迁移历史不一致，直接报错。

具体修复步骤 #

1. 先查清楚数据库里的旧记录 #

先登录你的数据库，执行这条SQL看看A、B、C这些应用的旧迁移记录：

SELECT * FROM django_migrations WHERE app IN ('A', 'B', 'C');

把这些记录记下来，确认是要清理的目标。

2. 清理数据库中的旧迁移记录 #

针对A、B、C应用，删掉对应的迁移记录：

DELETE FROM django_migrations WHERE app IN ('A', 'B', 'C');

⚠️ 划重点：如果是开发环境随便造数据的话放心操作；要是生产环境，一定要先备份数据库，确认没有依赖这些迁移的关键数据再动手！

3. 重新生成并同步迁移 #

先确认本地的migrations文件夹已经彻底删干净（你之前执行的rm -rf apps/*/migrations没问题，再检查下有没有残留的文件），然后重新生成迁移：

bin/dev/manage.py makemigrations A B C

接着执行迁移的时候，记得加--fake-initial参数：

bin/dev/manage.py migrate --fake-initial A B C

这个参数的作用是告诉Django：如果数据库里已经存在这些表（毕竟之前可能已经创建过），就假装已经执行了初始迁移，不用重复建表，只把新的迁移记录同步到数据库里。

4. 验证迁移状态 #

最后执行这条命令，确认所有迁移都被标记为已应用：

bin/dev/manage.py showmigrations A B C

要是所有迁移前面都有[X]，就说明问题解决了。

避坑小贴士 #

• 要是应用之间有外键关联，生成迁移的时候尽量按依赖顺序来（先跑被依赖的应用，再跑依赖它的），不过你说没有循环依赖，这一步应该不用太担心。
• 非必要别直接删migrations文件夹！开发环境测试阶段还好，生产环境这么做风险极高，尽量用--fake命令来调整迁移状态。

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