Django重跑makemigrations migrate后提示no such table报错排查

第一步：校验应用注册配置 #

检查项目settings.py的INSTALLED_APPS列表，必须包含两个应用的注册项，两种合法格式如下：

• 直接写应用名：'products'、'instructions'
• 完整AppConfig路径：'products.apps.ProductsConfig'、'instructions.apps.InstructionsConfig'

若应用的apps.py中自定义了AppConfig配置，必须填写完整路径，否则Django不会识别该应用。

第二步：清理历史无效迁移文件 #

分别进入products、instructions两个应用的migrations目录，删除除__init__.py之外的所有文件，注意不要删除__init__.py，否则会导致迁移生成失败。

第三步：重新生成并执行迁移 #

依次执行以下命令：

1. 针对两个应用单独生成迁移文件，避免全局检测遗漏：
   python manage.py makemigrations products instructions
2. 校验迁移对应的SQL逻辑，确认包含建表操作：
   python manage.py sqlmigrate products 0001
   正常输出会包含CREATE TABLE开头的建表语句，若无输出说明应用未被Django正确识别。
3. 执行全量迁移：
   python manage.py migrate

第四步：校验表生成结果 #

通过Django自带的数据库shell直接验证：
python manage.py dbshell
进入SQLite交互环境后执行：
.tables
查看输出列表中是否存在对应表：

• 若模型未自定义表名，默认表名为products_<模型类名小写>，比如模型类为Product则表名为products_product
• 若你在模型Meta中设置了db_table = 'products'，则检查表名是否为products

异常排查补充 #

• 若执行makemigrations时提示No changes detected，优先排查INSTALLED_APPS注册是否正确、models.py是否存在语法错误。
• 确认你删除的SQLite文件是settings.py中DATABASES配置指向的文件，避免删错其他位置的库文件。
• Windows环境下删除库文件后，先关闭所有运行中的Django服务，再执行迁移命令，避免文件被占用导致生成失败。
• 若报错提示找不到的表名为products而非默认的products_xxx，检查是否在代码中使用原生SQL硬编码了products表名，或模型Meta中配置的db_table与实际生成的表名不一致。

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