django迁移报错常见于django_migrations表残留记录导致inconsistentmigrationhistory或relation already exists。应先查删对应app的脏记录，再用--fake或--fake-initial修复，切忌盲目全删或硬删表。
django_migrations 表里有残留记录导致 migrate 报错
常见现象是执行 python manage.py migrate 时卡在某个迁移，或报 django.db.migrations.exceptions.InconsistentMigrationHistory。本质是 Django 认为「该迁的没迁」，但数据库其实已经存在对应表或字段——多半因为之前手动改过库、--fake 用得不干净，或多人协作时迁移文件没同步全。
直接删 django_migrations 表里的记录比删整个表更稳妥，尤其生产环境要避免误删其他 app 的迁移状态：
- 先查出目标 app 的迁移记录：
SELECT * FROM django_migrations WHERE app = 'your_app_name' ORDER BY applied DESC; - 确认哪些记录已实际生效（比如对应表确实存在），再删掉「标记为已应用但实际没执行」的脏记录
- 别用
TRUNCATE或全删，否则其他 app 的迁移历史会断
用 --fake 跳过已存在的表结构变更
当错误是 django.db.utils.ProgrammingError: relation "xxx" already exists，说明数据库里已有表，但 Django 还想建一遍。这时不能硬删表（可能丢数据），而应告诉 Django「这步你当它已完成」。
--fake 不碰数据库结构，只更新 django_migrations 表的记录：
- 对单个迁移：
python manage.py migrate your_app_name 0002_add_field --fake - 对全部未应用迁移：
python manage.py migrate your_app_name --fake - ⚠️ 前提是：数据库当前状态必须和该迁移文件描述的终态完全一致，否则后续迁移会崩
删除迁移文件 + 重走流程的适用场景
适合本地开发或测试环境，且你确定数据库可重来。常见于模型大改后迁移反复失败、或 makemigrations 生成了带冲突依赖的文件。
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
操作顺序不能错：
- 删掉所有非
__init__.py的迁移文件：find . -path "*/migrations/*.py" -not -name "__init__.py" -delete - 清空
django_migrations中对应 app 的记录（不是整个表） - 重新生成：
python manage.py makemigrations - 再用
--fake-initial启动：python manage.py migrate --fake-initial——这个参数专为「已有表但无迁移记录」设计，它只 fake 那个初始迁移（0001_initial），后续正常 migrate
为什么 --fake-initial 比 --fake 更安全
--fake-initial 有明确约束：只对名字为 0001_initial.py 且数据库中已存在对应表的迁移生效；而 --fake 无条件标记，容易掩盖字段缺失、约束不匹配等隐患。
典型误用是看到 relation already exists 就对所有迁移 --fake，结果后续加字段时报 no column Y——因为 Django 以为字段已存在，实际表里根本没那列。
真正要盯住的是迁移文件里的 operations 列表和数据库当前 schema 是否逐条对得上，而不是只看报错信息长什么样。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
