django报“no such table”错误通常因迁移记录与数据库结构不一致：未执行migrate、手动删改迁移文件或协作冲突导致。用showmigrations和sqlmigrate定位问题，避免直接删库；sqlite需检查路径、文件锁及内存数据库干扰。
django.core.exceptions.ProgrammingError: no such table 是什么情况
这错误不是数据库真丢了表，而是 Django 的迁移记录（django_migrations 表）和实际数据库结构对不上。常见两种可能：一是你写了 models.py 却没跑 python manage.py migrate；二是手动改过迁移文件、删过 migrations/ 里的文件，或者在多人协作中拉了别人没提交的迁移，导致本地迁移状态“以为自己执行过了”，其实没建表。
怎么快速确认是不是漏了 migrate
先别急着删库重来。用两条命令就能定位：
-
python manage.py showmigrations—— 看哪些迁移标了[X]（已执行），哪些是[ ]（待执行）。如果新模型对应的迁移是空括号，说明真漏了 -
python manage.py sqlmigrate app_name 0001—— 把对应迁移号换成你那个未执行的文件名（比如0002_add_field），看输出有没有建表语句。没有输出或报错，说明迁移文件本身有问题
注意：showmigrations 显示 “applied” 但表还是不存在？可能是迁移被标记为已执行但实际失败过（比如中间断过），这时得查 django_migrations 表里那条记录是否真有副作用。
迁移文件冲突或损坏后怎么安全修复
别直接删 migrations/ 目录或清空 django_migrations 表——尤其在线上或团队环境，这会引发更大同步问题。稳妥做法分三步：
- 先用
python manage.py migrate --plan看 Django 接下来打算执行哪些步骤，判断是否跳过了关键迁移 - 如果确认某次迁移该执行却没执行，且它不包含不可逆操作（比如
AlterField或DeleteModel），可尝试强制标记为已执行：python manage.py migrate app_name 0002 --fake（仅限你确定 SQL 已手动跑过） - 如果迁移文件本身有语法错误、重复定义、或和当前模型不匹配，删掉它和后续所有未应用的迁移文件，再重新
python manage.py makemigrations—— 但必须确保团队其他成员也同步这个新迁移，否则下次合并会再冲突
特别提醒：--fake-initial 只适用于首次把已有数据库接入 Django 的场景，不是用来绕过报错的万能开关。
SQLite 下 no such table 的特殊处理
SQLite 没有真正的“数据库用户权限”概念，所以问题往往更隐蔽：
- 检查
settings.py里的DATABASES['default']['NAME']路径是否写错，比如相对路径变成绝对路径后找不到文件，Django 会静默创建一个空库，自然没表 - SQLite 不支持并发写迁移，如果你在运行
runserver时同时跑migrate，可能因文件锁导致迁移中途退出，但django_migrations里已记上一笔——表实际没建成 - 用
sqlite3 db.sqlite3 ".tables"直接查，如果返回空，说明库确实是空的，重点就回到是不是路径错了或 migrate 根本没成功执行
最常被忽略的一点：Django 测试时默认用内存数据库（:memory:），而你开发时连的是文件数据库，两个完全隔离——别在测试命令里看到 “OK” 就以为迁移生效了。
