InconsistentMigrationHistory异常表明数据库迁移记录与文件依赖顺序不一致，主因是django_migrations表中admin.0001_initial执行早于其依赖user.0001_initial；常见于自定义User模型继承AbstractUser时未正确声明依赖或团队协作中迁移历史错乱。
迁移报错提示 InconsistentMigrationHistory
这是 Django 检测到迁移依赖顺序错乱时抛出的异常，典型报错信息长这样：django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency user.0001_initial。根本原因是数据库里 django_migrations 表记录的执行顺序，和迁移文件声明的依赖关系（dependencies 字段）对不上。
常见诱因包括：
- 手动删过某张表但没清理
django_migrations记录 - 团队协作中有人先
migrate了admin，又后加了自定义User模型并生成迁移，但依赖没显式声明 - 用
--fake过度后导致依赖链断裂
别急着删库。优先尝试：
- 检查出错 app 的迁移文件，打开
migrations/0001_initial.py，确认dependencies是否漏写了('auth', '0001_initial')或('myuser', '0001_initial') - 临时注释掉
INSTALLED_APPS中的'django.contrib.admin'，跑一次python manage.py migrate，再取消注释重跑 —— 这能绕过 admin 对 user 的隐式依赖 - 若确定数据库结构和模型完全一致，用
python manage.py migrate --fake-initial强制标记初始迁移为已应用（仅适用于真正从空库起步、且表已存在的情况）
Table 'xxx' already exists 或 relation "xxx" already exists
迁移脚本想建表，但数据库里同名表已经存在，Django 却没在 django_migrations 表里找到对应记录。这说明迁移历史“断连”了，不是代码问题，是元数据没对齐。
立即学习“Python免费学习笔记（深入）”；
直接删表或删库只适合本地环境。生产环境请按顺序操作：
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
- 进数据库 shell：
python manage.py dbshell - 查出问题 app 的迁移记录：
SELECT * FROM django_migrations WHERE app = 'your_app_name' ORDER BY applied DESC; - 删掉这些记录：
DELETE FROM django_migrations WHERE app = 'your_app_name'; - 回到命令行，重新生成迁移：
python manage.py makemigrations your_app_name（注意：不是makemigrations全局，避免误触其他 app） - 再执行：
python manage.py migrate your_app_name
如果连 makemigrations 都报错（比如提示 No changes detected），说明 Django 认为模型没变 —— 此时可删掉 your_app_name/migrations/ 下所有非 __init__.py 文件，再重试上面三步。
执行 migrate 卡住或报 OperationalError/ConnectionDoesNotExist
这类错误和迁移逻辑无关，是数据库连接层的问题。先排除基础配置：
- 检查
DATABASES配置里的NAME值：Windows 用户特别注意，如果用了pathlib.Path构造路径（如BASE_DIR / "db.sqlite3"），必须包一层str()，否则会触发TypeError: argument of type 'WindowsPath' is not iterable - PostgreSQL/MySQL 用户检查
USER、PASSWORD、HOST、PORT是否拼写正确，密码里有特殊字符要 URL 编码 - SQLite 用户确认
NAME路径有写权限，且目录存在（Django 不会自动创建父目录）
如果连接本身没问题，但迁移中途崩溃（比如 ALTER COLUMN 失败），数据库可能处于半完成状态。此时不要重复运行 migrate —— 先用 python manage.py showmigrations 看哪些迁移标了 [ ]（未应用），再针对性地用 python manage.py migrate your_app zero 回退到初始态，再重试。
字段增删后仍报 column "xxx" does not exist 或 IntegrityError
明明已跑过 migrate，代码里却还提示列不存在，或者插入时报 not-null 约束失败，大概率是迁移没真正生效。重点检查：
- 是否只对某个 app 执行了
migrate your_app，但忘了全局migrate？Django 默认只迁你指定的 app，其他 app 的依赖迁移不会自动触发 - 是否改了模型但没运行
makemigrations？尤其新增auto_now_add=True字段时，Django 会交互式要求你输入默认值，容易卡在终端没注意 - PostgreSQL 用户注意：某些版本对
NOT NULL字段添加约束极其严格，如果表里已有数据，Django 生成的迁移会拆成两步（先加列允许 NULL，再设 NOT NULL），但若中间中断，第二步就永远卡住 —— 此时需手动进数据库执行ALTER TABLE xxx ALTER COLUMN yyy SET NOT NULL;
最隐蔽的坑是：你改了模型、跑了 makemigrations、也跑了 migrate，但 Django 没报错，其实它悄悄跳过了这个迁移 —— 因为 django_migrations 表里已经有这条记录。务必用 showmigrations 核对状态，别只信终端输出的 “OK”。
