Django迁移失败主因是迁移文件、django_migrations表与数据库结构三者未对齐。常见错误包括删migrations文件却未清表记录、手动改库未同步状态、多环境共享数据库导致记录错位，修复须先核查三方一致性再操作。
因为 Django 的迁移系统依赖“迁移文件 + django_migrations 表 + 数据库真实结构”三者严格对齐，而新手常在其中任意一环手动干预，导致状态错位。
删过 migrations 文件夹但没清 django_migrations 表
这是最常见错误：本地改了 models.py，发现迁移失败，就直接删掉 app 下 migrations/ 里所有 .py 文件（除了 __init__.py），然后跑 makemigrations。但 django_migrations 表里还留着旧记录，Django 一看“这迁移我执行过了”，就不建表；可新生成的迁移又想 CREATE TABLE，MySQL 直接报 table “brand” already exists。
- 正确做法是先查清哪些迁移已记录：
SELECT * FROM django_migrations WHERE app = 'your_app_name'; - 再删对应行，不是删整个表，更不能只删文件夹
- 如果用的是 SQLite，
django_migrations就在db.sqlite3里，别漏查
MySQL 中手动删表或改字段后没同步迁移状态
比如在 MySQL 客户端里直接 DROP TABLE brand;，或者用 ALTER TABLE 加了个字段，之后再跑 migrate，就会触发 django.db.utils.ProgrammingError: 1146（表不存在）——Django 认为该表该由某次迁移创建，但数据库里没了。
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
- 这种情况不能靠
--fake补救，因为 fake 只标记“已执行”，不恢复结构 - 优先还原数据库表结构（比如从备份恢复），再让迁移对齐
- 若必须手动改表，改完立刻补一个空迁移：
python manage.py makemigrations your_app --empty，然后在生成的文件里写上operations = []，再migrate记录这次“人为变更”
多个环境共用同一份数据库或迁移文件
本地开发、测试服、甚至同事的机器，如果共享同一个 MySQL 实例，或者把 migrations/ 提交到 Git 后没处理好冲突，很容易出现“别人跑了迁移，你本地还没跑，但表已经存在”的情况。
- 迁移文件必须提交进 Git，但每次
makemigrations前先git pull，避免生成重复初始迁移 - 上线前务必确认
django_migrations表和目标库结构一致，可用python manage.py showmigrations对比 - 线上环境禁止直接
makemigrations，只允许migrate；所有模型变更必须先在本地生成迁移文件，再合入发布分支
真正难的不是命令怎么敲，而是判断“此刻哪一本账错了”。很多人卡住，是因为盯着报错信息找语法问题，却忘了先查 django_migrations 表里有没有那条记录、数据库里有没有那张表、本地 migrations/ 文件是不是和 Git 一致——这三处任何一处脱节，都会让 migrate 进入不可预测状态。
