部署Django执行makemigrations报错：Report_report表不存在，本地无异常

我之前也碰到过一模一样的情况！本地环境跑起来毫无问题，python manage.py check --deploy也没查出任何异常，但到了部署服务器上，别说makemigrations了，几乎所有manage命令都因为这个报错卡壳：

Traceback (most recent call last):
  File "/opt/pyapps/venv/lib/python3.8/site-packages/django/db/backends/utils.py", line 86, in _execute
    return self.cursor.execute(sql, params)
psycopg2.errors.UndefinedTable: relation "Report_report" does not exist
LINE 1: SELECT "Report_report"."id" FROM "Report_report" ORDER BY "R..

这个问题的核心是：Django在执行很多manage命令时，会提前初始化应用、加载信号或中间件，而如果这些逻辑里有启动时就访问数据库的代码，此时数据库里还没有Report_report表，就会触发这个错误。下面是几个亲测有效的解决办法：

• 临时注释触发数据库查询的代码
  去检查Report应用的apps.py（尤其是ready()方法）、signals.py，或者全局的中间件配置，看看有没有在项目启动时就执行数据库查询的逻辑——比如在ready()里调用Report.objects.all()初始化数据，或者信号接收器里直接查询数据库。先把这些代码注释掉，等完成迁移后再恢复。另外，第三方中间件也可能踩这个坑，你可以临时在settings.py的MIDDLEWARE里注释掉非必需的中间件。

• 用--fake-initial跳过初始表检查
  如果服务器数据库是全新的，或者之前的迁移记录和数据库状态不一致，可以先执行这条命令：

  python manage.py makemigrations --fake-initial
  

  它会告诉Django：那些对应已有表的初始迁移已经完成，不用再去数据库里验证。之后再正常执行migrate就能创建剩下的表。

• 确认数据库配置和权限
  别忽略最基础的检查：服务器上的PostgreSQL数据库是否已经正确创建？settings.py里的DATABASES配置（数据库名、用户名、密码、主机）有没有写错？数据库用户有没有足够的权限创建表？这些小细节很容易漏掉。

• 调整INSTALLED_APPS的顺序
  如果Report应用被其他应用依赖，而它在INSTALLED_APPS里的位置太靠后，可能会导致依赖它的应用先加载并触发数据库查询。把Report移到INSTALLED_APPS的前面试试。

按上面的步骤操作后，应该就能顺利执行makemigrations和migrate了。

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