症状
应用能正常启动、健康检查也能响应，但对某个模型的首次查询就抛出 OperationalError: no such table，消息里是 Django 由 app label 与模型名推导出的表名。测试可能通过，因为测试会自建 schema，而运行中的服务失败，这正是两个进程未使用同一数据库的线索。
诊断
先用 dbshell 确认进程实际连的库，再用 showmigrations 查看迁移是否已应用；检查 diffsettings 里的 settings 模块与数据库别名，最后直接查库文件确认表是否存在。
python manage.py dbshell根因
运行进程连接的数据库从未执行过创建该表的迁移，通常是 settings 或环境变量错配，而非迁移本身损坏。
修复
对应用实际使用的数据库执行 migrate，并确认 settings 模块与数据库别名与部署一致；提交迁移文件以便各环境应用相同 schema，避免环境变量缺失时静默回退到别的库。
验证
修复后重启服务、重放失败的请求，再对该目标库执行 showmigrations，确认迁移已应用；查询成功与迁移被勾选共同证明表已存在于应用期望的位置。
常见陷阱
对错误的库执行 migrate 会在开发文件里建表而生产仍然坏掉，迁移前务必确认目标连接。