Django3.2+MySQL5.7创建测试库报CurrentArticle表不存在错误

核心问题出在managed模型配置和Django迁移状态机的执行逻辑差上，测试库从零构建的场景把历史迁移的隐藏问题暴露了出来：

• 初始导入CurrentArticle外部表时，模型设置了managed = False，生成0001_initial迁移时，Django虽然在迁移状态文件里记录了该模型的存在，但不会实际执行这张表的建表SQL——这个配置本来就是告诉Django“这张表不归你管，不要建不要改”，生产环境因为提前导入了外部表，所以不会出问题。
• 0002迁移移除managed=False配置时，Django只会生成AlterModelOptions的操作更新模型元配置，不会自动补建之前跳过的CurrentArticle表。因为迁移状态机默认“之前的迁移已经把表建好了”，不会回溯校验实际库中表是否存在。
• 到0003迁移执行加字段、改字段类型的操作时，需要操作test_hopi_django.CurrentArticle表，但空测试库里从一开始就没建过这张表，直接触发表不存在的报错。
• 开头提示的(1007, "Can't create database 'test_hopi_django'; database exists")是之前测试异常中断残留的旧测试库，属于连带现象，不是核心故障点。

• 补全缺失的建表操作
  在articles应用的0002迁移（即修改managed配置的那笔迁移）的操作列表最开头，补充CurrentArticle的CreateModel操作，字段定义和0001迁移里记录的CurrentArticle初始结构完全一致即可。
  如果怕手写出错，可以按这个流程生成标准操作：
  1. 临时把CurrentArticle模型的managed改回False
  2. 执行./manage.py makemigrations articles --empty生成一笔空迁移，把文件序号调整到0002和0003之间
  3. 再把模型的managed改回True，执行./manage.py makemigrations articles，这时候生成的迁移里会自动带上正确的CreateModel操作，把这段操作代码剪切到刚才生成的空迁移里，删掉多余的迁移文件即可。
• 清理残留测试库
  登录MySQL执行DROP DATABASE IF EXISTS test_hopi_django;，删掉之前异常中断留下的旧测试库，避免后续跑测试时反复弹出库存在的交互提示。
• 验证迁移正确性
  先不直接跑全量测试，新建空测试库后执行./manage.py migrate，确认所有迁移正常执行、所有表都创建完成，再执行./manage.py test运行单元测试即可。

• 补了CreateModel操作的迁移在生产环境执行不会影响现有数据，Django检测到表已存在时会自动跳过建表步骤，不会重复建表或删改现有数据。
• 后续凡是遇到初始managed=False后续改为Django托管的模型，一定要在修改managed属性的同笔迁移里补全建表操作，否则所有空库部署场景（新环境搭建、测试库构建）都会触发同类表不存在错误。

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